Conversation

twitter.com/ottom6k/status This is also the case on GrapheneOS with hardened_malloc, and with the previous port of OpenBSD malloc. The behavior of freeing on realloc of size 0 comes from glibc and was copied by jemalloc for compatibility. Android got it when adopting jemalloc.

This Tweet is unavailable.

Daniel Micay

@DanielMicay

Oct 9, 2019

Relevant code in jemalloc: github.com/jemalloc/jemal Android has a Compatibility Test Suite (CTS) test checking for the non-compliant glibc/jemalloc behavior. Can see that I marked it as an intentional failure in this 10 month old CTS results comparison:

gist.github.com

hardened.diff

GitHub Gist: instantly share code, notes, and snippets.

Daniel Micay

@DanielMicay

Oct 9, 2019

The other real failures identified there (as opposed to flaky tests) ended up being upstream memory corruption bugs, most of which are now addressed. CTS is a massive test suite incorporating a bunch of internal/external test suites & often I consider the bug to be in the test...

Daniel Micay

@DanielMicay

Oct 9, 2019

I would much rather have memory leaks than double frees and software relying on realloc of size 0 to free memory is expecting dangerous non-standards-compliant behavior. It's a backwards compatibility hack with serious consequences as can be seen from this WhatsApp vulnerability.

Daniel Micay

@DanielMicay

I felt a bit uneasy about breaking compatibility like this, but this is a nice confirmation that I'm doing the right thing in this case. I try to avoid causing CTS failures, but sometimes the CTS is wrong and I'm perfectly happy to have a couple dozen well understood failures.

3:56 PM · Oct 9, 2019Twitter Web App

Retweet

Likes