[Bug malloc/25945] ASLR information leak via Safe-Linking and tcache or fastbin chunks.

["carlos at redhat dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=25945

--- Comment #9 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to wangxu from comment #7)
> Thanks for patient reply.
> I'm considering whether there's a more blanket solution. Thanks again.
> 
> BTW, is it better to give a change to perturb pointers returned by
> tcache_get(), using alloc_perturb (p, bytes) ?

This is a *distinct* issue. Should M_PERTURB effect tcache? I think it should,
so please file another bug for this.

The issue we are talking about today is the prevention of ASLR bits leaking
from known locations in the chunk metadata. If we can reduce this leakage with
minimal performance loss, because the data is already in the cache and the
write is cheap, then that has value.

I haven't seen any more responses on OSS Security regarding the issue of
allocating a CVE. Our current policy is that "Information disclosure can be
security bugs, especially if exposure through applications can be determined."
and in this case we have no direct exposure through applications that we know
about, so I think allocating a CVE, particularly for an unreleased version of
glibc, is premature.

In which case we should continue working on this as a patch to fix the ASLR
leakage.

Could you please review my comments in
https://sourceware.org/bugzilla/show_bug.cgi?id=25945#c3 and review that we
need to clear the pointers for tcache *and* fastbin?

After such review, please post a patch to libc-alpha for review. It would be
good if you run `make bench` before and after your patch and review the malloc
performance doesn't show any unexpected problems (bench-malloc-simple,
bench-malloc-thread). Likewise confirm no regressions on x86_64.

Thanks.

-- 
You are receiving this mail because:
You are on the CC list for the bug.