[Bug libc/32026] New: strerror, strsignal TLS not handled correctly for secondary namespaces (dlmopen, LD_AUDIT)

[Bug libc/32026] New: strerror, strsignal TLS not handled correctly for secondary namespaces (dlmopen, LD_AUDIT)

[fweimer at redhat dot com]

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

            Bug ID: 32026
           Summary: strerror, strsignal TLS not handled correctly for
                    secondary namespaces (dlmopen, LD_AUDIT)
           Product: glibc
           Version: 2.41
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: fweimer at redhat dot com
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---

The test case below shows that it's possible that the per-thread buffer for
strerror, strsignal can be allocated by one namespace, but deallocated by
another namespace. Fixing this will be a bit tricky, probably similar to how
bug 24773 was handled.

Alternatively, we move these buffers into initial-exec TLS, so that they get
duplicated in audit namespaces, but this will need something to invoke
secondary cleanup functions on thread exit. Or we do not include the numbers in
secondary namespaces.

#include <array_length.h>
#include <errno.h>
#include <gnu/lib-names.h>
#include <string.h>
#include <support/check.h>
#include <support/xdlfcn.h>
#include <support/xthread.h>
#include <support/support.h>

/* strerror function in dlmopen'ed libc.  */
static __typeof (strerror) *strerror_ptr;

/* Run strerror on a separate thread.  */
static void *
do_strerror (void *ignore)
{
  TEST_COMPARE_STRING (strerror_ptr (123456), "Unknown error 123456");
  /* Exiting the thread should deallocate the string using the correct
     allocator.  */
  return NULL;
}

static int
do_test (void)
{
  mallopt (M_MXFAST, 0);

  TEST_COMPARE_STRING (strerror (ENOENT), "No such file or directory");

  void *handle = xdlmopen (LM_ID_NEWLM, LIBC_SO, RTLD_NOW);
  strerror_ptr = xdlsym (handle, "strerror");
  TEST_VERIFY (strerror != strerror_ptr);

  TEST_COMPARE_STRING (strerror_ptr (ENOENT), "No such file or directory");

  void *volatile ptrs[500];

  for (int i = 0; i < array_length (ptrs); )
    {
      xpthread_join (xpthread_create (NULL, do_strerror, NULL));
      ptrs[i++] = xstrdup ("Unknown error 123456");
    }

  for (int i = 0; i < array_length (ptrs); i++)
    free (ptrs[i]);

  xdlclose (handle);

  return 0;
}

#include <support/test-driver.c>

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

[Bug libc/32026] strerror, strsignal TLS not handled correctly for secondary namespaces (dlmopen, LD_AUDIT)

[fweimer at redhat dot com]

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

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fweimer at redhat dot com

--- Comment #1 from Florian Weimer <fweimer at redhat dot com> ---
I should have said that this was found while reading the code, no application
impact is known. Auditors probably shouldn't call strerror, strsignal anyway
because that alters application state outside the auditor, without a way to
restore it.

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

[Bug libc/32026] strerror, strsignal TLS not handled correctly for secondary namespaces (dlmopen, LD_AUDIT)

[fweimer at redhat dot com]

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

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |security-
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at sourceware dot org   |fweimer at redhat dot com

--- Comment #2 from Florian Weimer <fweimer at redhat dot com> ---
Not a security bug. The description of strerror, strsignal is already clear
enough that using these functions from libraries can introduce memory
corruption because strings are freed.

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

[Bug libc/32026] strerror, strsignal TLS not handled correctly for secondary namespaces (dlmopen, LD_AUDIT)

[fweimer at redhat dot com]

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

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |2.41
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #3 from Florian Weimer <fweimer at redhat dot com> ---
Fixed for 2.41 via:

commit 25a5eb4010df94b412c67db9e346029de316d06b
Author: Florian Weimer <fweimer@redhat.com>
Date:   Mon Aug 19 15:48:03 2024 +0200

    string: strerror, strsignal cannot use buffer after dlmopen (bug 32026)

    Secondary namespaces have a different malloc.  Allocating the
    buffer in one namespace and freeing it another results in
    heap corruption.  Fix this by using a static string (potentially
    translated) in secondary namespaces.  It would also be possible
    to use the malloc from the initial namespace to manage the
    buffer, but these functions would still not be safe to use in
    auditors etc. because a call to strerror could still free a
    buffer while it is used by the application.  Another approach
    could use proper initial-exec TLS, duplicated in secondary
    namespaces, but that would need a callback interface for freeing
    libc resources in namespaces on thread exit, which does not exist
    today.

    Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>

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