Hello community,
here is the log from the commit of package glibc for openSUSE:Leap:15.2 checked
in at 2020-05-29 18:49:03
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Comparing /work/SRC/openSUSE:Leap:15.2/glibc (Old)
and /work/SRC/openSUSE:Leap:15.2/.glibc.new.3606 (New)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Package is "glibc"
Fri May 29 18:49:03 2020 rev:74 rq:808978 version:2.26
Changes:
--------
--- /work/SRC/openSUSE:Leap:15.2/glibc/glibc.changes 2020-04-08
12:47:44.422323005 +0200
+++ /work/SRC/openSUSE:Leap:15.2/.glibc.new.3606/glibc.changes 2020-05-29
18:49:04.088183903 +0200
@@ -1,0 +2,6 @@
+Wed May 13 10:27:17 UTC 2020 - Andreas Schwab <sch...@suse.de>
+
+- nptl-setxid-race.patch: nptl: wait for pending setxid request also in
+ detached thread (bsc#1162930, BZ #25942)
+
+-------------------------------------------------------------------
New:
----
nptl-setxid-race.patch
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Other differences:
------------------
++++++ glibc.spec ++++++
--- /var/tmp/diff_new_pack.KMdvGb/_old 2020-05-29 18:49:05.576188173 +0200
+++ /var/tmp/diff_new_pack.KMdvGb/_new 2020-05-29 18:49:05.580188184 +0200
@@ -430,6 +430,8 @@
Patch1080: dlopen-filter-object.patch
# PATCH-FIX-UPSTREAM Fix use-after-free in glob when expanding ~user
(CVE-2020-1752, BZ #25414)
Patch1081: glob-use-after-free.patch
+# PATCH-FIX-UPSTREAM nptl: wait for pending setxid request also in detached
thread (BZ #25942)
+Patch1082: nptl-setxid-race.patch
###
# Patches awaiting upstream approval
@@ -746,6 +748,7 @@
%patch1079 -p1
%patch1080 -p1
%patch1081 -p1
+%patch1082 -p1
%patch2000 -p1
%patch2001 -p1
++++++ nptl-setxid-race.patch ++++++
>From 4cab20fa49b3ea3e3454fdc4f13bf3828d8efd19 Mon Sep 17 00:00:00 2001
From: Andreas Schwab <sch...@suse.de>
Date: Thu, 7 May 2020 15:50:09 +0200
Subject: [PATCH] nptl: wait for pending setxid request also in detached thread
(bug 25942)
There is a race between __nptl_setxid and exiting detached thread, which
causes a deadlock on stack_cache_lock. The deadlock happens in this
state:
T1: setgroups -> __nptl_setxid (holding stack_cache_lock, waiting on cmdp->cntr
== 0)
T2 (detached, exiting): start_thread -> __deallocate_stack (waiting on
stack_cache_lock)
more threads waiting on stack_cache_lock in pthread_create
For non-detached threads, start_thread waits for its own setxid handler to
finish before exiting. Do this for detached threads as well.
---
nptl/pthread_create.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
Index: glibc-2.26/nptl/pthread_create.c
===================================================================
--- glibc-2.26.orig/nptl/pthread_create.c
+++ glibc-2.26/nptl/pthread_create.c
@@ -577,11 +577,7 @@ START_THREAD_DEFN
}
#endif
- /* If the thread is detached free the TCB. */
- if (IS_DETACHED (pd))
- /* Free the TCB. */
- __free_tcb (pd);
- else if (__glibc_unlikely (pd->cancelhandling & SETXID_BITMASK))
+ if (__glibc_unlikely (pd->cancelhandling & SETXID_BITMASK))
{
/* Some other thread might call any of the setXid functions and expect
us to reply. In this case wait until we did that. */
@@ -597,6 +593,11 @@ START_THREAD_DEFN
pd->setxid_futex = 0;
}
+ /* If the thread is detached free the TCB. */
+ if (IS_DETACHED (pd))
+ /* Free the TCB. */
+ __free_tcb (pd);
+
/* We cannot call '_exit' here. '_exit' will terminate the process.
The 'exit' implementation in the kernel will signal when the
