[Bug nptl/25098] New: nptl: ctype classification functions are not AS-Safe

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[Bug nptl/25098] New: nptl: ctype classification functions are not AS-Safe

glaubitz at physik dot fu-berlin.de
https://sourceware.org/bugzilla/show_bug.cgi?id=25098

            Bug ID: 25098
           Summary: nptl: ctype classification functions are not AS-Safe
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: nptl
          Assignee: unassigned at sourceware dot org
          Reporter: fweimer at redhat dot com
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---
             Flags: security-

A signal can arrive on a new thread before __ctype_init has completed on that
thread.

Pointed out by Mathieu Desnoyers as part of the rseq work.

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug nptl/25098] nptl: ctype classification functions are not AS-Safe

glaubitz at physik dot fu-berlin.de
https://sourceware.org/bugzilla/show_bug.cgi?id=25098

Florian Weimer <fweimer at redhat dot com> changed:

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

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug nptl/25098] nptl: ctype classification functions are not AS-Safe

glaubitz at physik dot fu-berlin.de
In reply to this post by glaubitz at physik dot fu-berlin.de
https://sourceware.org/bugzilla/show_bug.cgi?id=25098

--- Comment #1 from Florian Weimer <fweimer at redhat dot com> ---
Patch posted: https://sourceware.org/ml/libc-alpha/2019-10/msg00383.html

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug nptl/25098] nptl: ctype classification functions are not AS-Safe

glaubitz at physik dot fu-berlin.de
In reply to this post by glaubitz at physik dot fu-berlin.de
https://sourceware.org/bugzilla/show_bug.cgi?id=25098

Emilio Cobos Álvarez (:emilio) <emilio at crisal dot io> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |emilio at crisal dot io

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug nptl/25098] nptl: ctype classification functions are not AS-Safe

Sourceware - glibc-bugs mailing list
In reply to this post by glaubitz at physik dot fu-berlin.de
https://sourceware.org/bugzilla/show_bug.cgi?id=25098

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
                 CC|                            |fweimer at redhat dot com
   Target Milestone|---                         |2.32
             Status|ASSIGNED                    |RESOLVED

--- Comment #2 from Florian Weimer <fweimer at redhat dot com> ---
Fixed for glibc 2.32:

commit b3cae39dcbfa2432b3f3aa28854d8ac57f0de1b8
Author: Florian Weimer <[hidden email]>
Date:   Mon Apr 27 09:55:10 2020 +0200

    nptl: Start new threads with all signals blocked [BZ #25098]

    New threads inherit the signal mask from the current thread.  This
    means that signal handlers can run on the newly created thread
    immediately after the kernel has created the userspace thread, even
    before glibc has initialized the TCB.  Consequently, new threads can
    observe uninitialized ctype data, among other things.

    To address this, block all signals before starting the thread, and
    pass the original signal mask to the start routine wrapper.  On the
    new thread, first perform all thread initialization, and then unblock
    signals.

    The cost of doing this is two rt_sigprocmask system calls on the old
    thread, and one rt_sigprocmask system call on the new thread.  (If
    there was a way to clone a new thread with a signals disabled, this
    could be brought down to one system call each.)  The thread descriptor
    increases in size, too, and sigset_t is fairly large.  This increase
    could be brought down by reusing space the in the descriptor which is
    not needed before running user code, or by switching to an internal
    sigset_t definition which only covers the signals supported by the
    kernel definition.  (Part of the thread descriptor size increase is
    already offset by reduced stack usage in the thread start wrapper
    routine after this commit.)

    Reviewed-by: Carlos O'Donell <[hidden email]>

Also needs the following regression fix (plus its dependencies):

commit ba9f6ee9bb8a894c9e2fb715edf693dd157b420a
Author: Florian Weimer <[hidden email]>
Date:   Tue May 19 12:03:44 2020 +0200

    Linux: Use __pthread_attr_setsigmask_internal for timer helper thread

    timer_create needs to create threads with all signals blocked,
    including SIGTIMER (which happens to equal SIGCANCEL).

    Fixes commit b3cae39dcbfa2432b3f3aa28854d8ac57f0de1b8 ("nptl: Start
    new threads with all signals blocked [BZ #25098]").

    Reviewed-by: Carlos O'Donell <[hidden email]>

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