The only problem OP has solved is detecting overwriting of metadata inadvisably comingled with the user data.
That problem does simply not exist in phkmalloc, or jemalloc for that matter, writing past the end or before the beginning of an allocation does not automatically give you the ability to violate the internal integrity of the malloc implementation.
If you actually read the first link you pasted carefully, you will see what an amazing tour-de-force it was to exploit CVE-2003-0015, which was a run-of-the-mill double-free mistake in CVS.
As I remember it, there were proof-of-concept exploits against list-based mallocs in a matter of days, it took months before bbp's article appeared.
When I wrote phkmalloc, most of the exploitable malloc-related problems were usage problems, double frees, freeing modified pointers, writing past start or end of allocation etc.
If you had seen my presentation in New Orleans 1998, you would undoubtedly remember my handwritten slide with around 20 setuid programs phkmalloc had found issues in within the first year.
That is the primary reason why there are so few malloc(3) related exploits these days: phkmalloc and later jemalloc complained about them.
Those are mistakes which list-based mallocs do not find, because it is too expensive to walk the list all the time, and on top of that, they run slower, because the list is O(n)!
There is neither a reason, nor an excuse for using a list-based malloc in this day and age.
Neither OP nor I claim to have solved the "big" malloc problem, because, as I already explained: That takes hardware support.
Comments
No ?
The only problem OP has solved is detecting overwriting of metadata inadvisably comingled with the user data.
That problem does simply not exist in phkmalloc, or jemalloc for that matter, writing past the end or before the beginning of an allocation does not automatically give you the ability to violate the internal integrity of the malloc implementation.
If you actually read the first link you pasted carefully, you will see what an amazing tour-de-force it was to exploit CVE-2003-0015, which was a run-of-the-mill double-free mistake in CVS.
As I remember it, there were proof-of-concept exploits against list-based mallocs in a matter of days, it took months before bbp's article appeared.
When I wrote phkmalloc, most of the exploitable malloc-related problems were usage problems, double frees, freeing modified pointers, writing past start or end of allocation etc.
If you had seen my presentation in New Orleans 1998, you would undoubtedly remember my handwritten slide with around 20 setuid programs phkmalloc had found issues in within the first year.
That is the primary reason why there are so few malloc(3) related exploits these days: phkmalloc and later jemalloc complained about them.
Those are mistakes which list-based mallocs do not find, because it is too expensive to walk the list all the time, and on top of that, they run slower, because the list is O(n)!
There is neither a reason, nor an excuse for using a list-based malloc in this day and age.
Neither OP nor I claim to have solved the "big" malloc problem, because, as I already explained: That takes hardware support.