HiKey and HiKey 960 boot process stalls with hardened malloc in debug builds

[thestinger]

In debug builds, the hardened malloc uses non-zero-based junk filling (0xdf bytes) and fully random heap canaries rather than using a zero prefix. There's at least one memory corruption bug on HiKey / HiKey 960 causing this to break something. It might be a use-after-free but it could also be uninitialized data usage.

[thestinger]

unmodified: breaks leading zero in canary enabled: breaks junk free disabled: often works zero-based junk free: (always?) works

[thestinger]

It seems more likely this is an uninitialized memory usage bug than use-after-free.

[thestinger]

It breaks with this change to enable non-zero fill on init while still forcing zero fill on free so it must be uninitialized memory usage:

diff --git a/libc/bionic/omalloc.c b/libc/bionic/omalloc.c
index ded9520f2..d4c17e9a6 100644
--- a/libc/bionic/omalloc.c
+++ b/libc/bionic/omalloc.c
@@ -136,7 +136,7 @@ static void _MALLOC_UNLOCK(int mutex)
 /*#define SOME_JUNK        0xd0    [> as in "Duh" :-) <]*/
 /*#define SOME_FREEJUNK        0xdf*/
 /*#else*/
-#define SOME_JUNK      0
+#define SOME_JUNK      0xdf
 #define SOME_FREEJUNK      0
 /*#endif*/

@@ -726,6 +726,7 @@ omalloc_init(void)
     */
    mopts.malloc_canaries = sizeof(void *);
    mopts.malloc_junk = 1;
+   mopts.malloc_junk_init = 1;
    mopts.malloc_move = 1;
    mopts.malloc_xmalloc = 1;
    mopts.malloc_cache = MALLOC_DEFAULT_CACHE;

[thestinger]

No longer going to be dealing with support for these devices at this time.