4 ms·
Sure, my patches are linked in the bugs I filed: https://sourceware.org/bugzilla/show_bug.cgi?id=24026 https://sourceware.org/bugzilla/show_bug.cgi?id=24026 -
by nh2 7y ago
Sure, my patches are linked in the bugs I filed:
https://sourceware.org/bugzilla/show_bug.cgi?id=24026 https://sourceware.org/bugzilla/show_bug.cgi?id=24026 - "malloc_info() returns wrong numbers"
https://sourceware.org/bugzilla/show_bug.cgi?id=21556 https://sourceware.org/bugzilla/show_bug.cgi?id=21556 - "malloc_stats printing size_t fields as unsigned int"
If you're interested in this topic:
After finding one bug after the other due to 32-bit integer overflow in malloc.c, I just searched for "unsigned int" in that file for fun, and 30 seconds later found what I consider a security vulnerability in realloc():
https://sourceware.org/bugzilla/show_bug.cgi?id=24027 https://sourceware.org/bugzilla/show_bug.cgi?id=24027
In certain situations, if you realloc() e.g. 32G + 5 bytes (reallocs this large can happen in large programs e.g. for data analysis), it'll copy only 5 bytes, and leave the rest as memory garbage.
That experience taught me that open source code being old doesn't mean anybody ever read it.
- rurban 7y agopt2malloc is only maintained by glibc, but not really. Since they cannot maintain it, they want to get rid of it. The upstream maintainer released a better version pt3malloc, which glibc refused to adopt. It needs one more word per alloc.