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

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.

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

Replying to

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

Oct 9, 2019

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.