This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: malloc_set_state and heap content
- From: Samuel Thibault <samuel dot thibault at ens-lyon dot org>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Wed, 6 Jul 2016 22:38:30 +0200
- Subject: Re: malloc_set_state and heap content
- Authentication-results: sourceware.org; auth=none
- References: <20160320164214.GA21096@var.home> <20160706193547.GD8550@var.home> <525e1911-1eb5-682c-942c-d1b67a081c03@redhat.com>
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.
> >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? :)
Samuel