This landed upstream in the July functional update (it wasn't a security fix):
android.googlesource.com/platform/exter
I've verified that this resolves the compatibility issue with hardened_malloc due to zero-on-free and other use-after-free mitigations. It's nice to drop another workaround.
Conversation
I often fix these issues myself downstream as github.com/GrapheneOS/har compatibility fixes, but I don't have unlimited time and sometimes need to disable features for certain processes as I did here once I confirmed it wasn't a security issue. The issues are usually in new code.
1
1
The Android Open Source Project (AOSP) supports full ASan builds and is tested in that configuration upstream. Over time, latent memory corruption is going away. New code brings new bugs. Device-specific code such as this Titan M driver is less tested. New drivers are the worst.
1
I run into far fewer of these bugs with AOSP compared to using github.com/GrapheneOS/har with the desktop or server Linux software stacks. However, they're clearly not blocking releases on being ASan clean for a run of the Compatibility Test Suite (CTS) and Vendor Test Suite (VTS).
1
1
I think they should be blocking releases on that. I obviously don't expect any substantial C or C++ code to be free of memory corruption bugs. However, I think it's quite reasonable to expect stable releases to be free of memory corruption caught by ASan during standard tests.
1
3
Memory tagging is going to help with this because there will likely be memory tagging for the malloc heap in production, which essentially provides a much more efficient form of ASan in production with abort on failure. See github.com/GrapheneOS/har for my own plans on using MTE.
Replying to
Memory tagging will prevent taking the shortcut of solving ASan reports later, which seems to be the issue still occasionally happening for AOSP. Most people aren't testing with ASan as rigorously as AOSP (compiling all libraries, etc. with it) and they'll find tagging painful...