Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
HiKey and HiKey 960 boot process stalls with hardened malloc in debug builds #797
Comments
thestinger
added
Component: hardened malloc
Device: HiKey
Device: HiKey 960
Type: bug
upstream
labels
Oct 30, 2017
thestinger
added
the
Priority: high
label
Oct 30, 2017
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
thestinger
Oct 30, 2017
Contributor
unmodified: breaks
leading zero in canary enabled: breaks
junk free disabled: often works
zero-based junk free: (always?) works
|
unmodified: breaks |
thestinger
added
the
Status: workaround in place
label
Oct 30, 2017
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
thestinger
Oct 30, 2017
Contributor
It seems more likely this is an uninitialized memory usage bug than use-after-free.
|
It seems more likely this is an uninitialized memory usage bug than use-after-free. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
thestinger
Oct 30, 2017
Contributor
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;|
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 commentedOct 30, 2017
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.