This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Thread stack and heap caches - CVE-2019-1010024
- From: Florian Weimer <fweimer at redhat dot com>
- To: Vinay Kumar <vinay dot m dot engg at gmail dot com>
- Cc: libc-alpha at sourceware dot org, carlos at redhat dot com
- Date: Mon, 04 Nov 2019 13:25:44 +0100
- Subject: Re: Thread stack and heap caches - CVE-2019-1010024
- References: <CANUMPcXr+asjC32M1qENUEkBvNj4SGsvE6jNNwsV55H5EhkRiw@mail.gmail.com>
* Vinay Kumar:
> Regarding bug related to Thread stack and heap caches (CVE-2019-1010024).
> https://sourceware.org/bugzilla/show_bug.cgi?id=22852
>
>>> One way to harden is to use a tunable for a thread stack cache, and set that to zero.
> Below change in glibc allocatestack.c file gives the expected output
> with test case. Verified on x86_64 target.
> =======================================================
> --- a/nptl/allocatestack.c
> +++ b/nptl/allocatestack.c
> @@ -186,6 +186,7 @@ get_cached_stack (size_t *sizep, void **memp)
> struct pthread *curr;
>
> curr = list_entry (entry, struct pthread, list);
> + curr->stackblock_size = 0;
> if (FREE_P (curr) && curr->stackblock_size >= size)
> {
> if (curr->stackblock_size == size)
> =======================================================
Does this really change the randomization? Won't the kernel map the new
stack at a predictable address, too?
Thanks,
Florian