This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 07/06/2016 10:38 PM, Samuel Thibault wrote:
Florian Weimer, on Wed 06 Jul 2016 22:36:05 +0200, wrote:On 07/06/2016 09:35 PM, Samuel Thibault wrote:On Linux the space happens to be zero by luck, but with other kernels that may not be true (it is not with the Hurd).How gets Hurd away with that without introducing a security vulnerability?What remains on the heap is initialization stuff, not remainders from pages allocated by the kernel.
I still don't see how this is correct. Maybe the Hurd startup code mallocs so much that it consumes all that data before the application can call calloc. Otherwise, an early calloc call would return non-zero memory.
So I'd say we need the attached patch, don't we?The patch does not address the issue because it does not alter the heap copy in existing Emacs binaries. It would only become effective after recompiling Emacs. Such recompiled Emacs binaries will no longer use the heap dumping mechanism.Well, glibc is not only about emacs, is it? :)
Could you be more specific, please? Are there Hurd-specific applications which use malloc_set_state?
Thanks, Florian
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |