Re: Thread stack and heap caches - CVE-2019-1010024

[Florian Weimer <fweimer@redhat.com>]

* Vinay Kumar:

> Hi,
>
> 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)
> =======================================================

This will just cause crashes (abort in free_statcks).

I tried to emulate the effect with this program:

#include <err.h>
#include <errno.h>
#include <pthread.h>
#include <stddef.h>
#include <stdint.h>
#include <stdio.h>

static void *
thread (void *closure)
{
  uintptr_t *pp = closure;
  *pp = (uintptr_t) &pp;
  return NULL;
}

int
main (void)
{
  pthread_attr_t attr;
  int ret = pthread_attr_init (&attr);
  if (ret != 0)
    {
      errno = ret;
      err (1, "pthread_attr_init");
    }
  ret = pthread_attr_setstacksize (&attr, 128 * 1024 * 1024);
  if (ret != 0)
    {
      errno = ret;
      err (1, "pthread_attr_setstacksize");
    }

  for (int i = 0; i < 20; ++i)
    {
      pthread_t thr;
      uintptr_t ptr;
      ret = pthread_create (&thr, &attr, thread, &ptr);
      if (ret != 0)
        {
          errno = ret;
          err (1, "pthread_create");
        }
      ret = pthread_join (thr, NULL);
      if (ret != 0)
        {
          errno = ret;
          err (1, "pthread_join");
        }
      printf ("%p\n", (void *) ptr);
    }
}

Its stack size is so large that the stack is never cached.  If you run
it with strace, you will see that mmap and munmap is called for each
iteration.

As I suspected, it prints the same address again and again because the
kernel does NOT randomize mappings.  Until that happens, there is not
much value in disabling the stack cache.

Thanks,
Florian