Bug 14830 - Race conditions with signals and thread priority scheduling
Summary: Race conditions with signals and thread priority scheduling
Status: RESOLVED DUPLICATE of bug 25098
Alias: None
Product: glibc
Classification: Unclassified
Component: nptl (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-11-11 20:50 UTC by Rich Felker
Modified: 2021-05-27 00:32 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:
fweimer: security-


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rich Felker 2012-11-11 20:50:38 UTC
NPTL implements thread priority scheduling for new threads by creating the new thread but blocking its forward progress until pthread_create in the parent can set the new thread's scheduling options. If this fails (e.g. due to EPERM), pthread_create is required to fail. To achieve this result, NPTL has pthread_create send a cancellation request to the new thread.

Unfortunately, NPTL fails to block signals during thread creation, so it's possible that a signal handler is already running (at the wrong priority) in the newly created thread by the time the failure to set the priority had been detected. The cancellation request will then cause any cancellation-point function called from the signal handler to act upon cancellation, possibly with disastrous results if the application was not written to use cancellation.

I believe the simplest solution to this issue is to block all signals before clone() is called. In the parent, signals can be unblocked immediately as soon as clone returns. In the new thread, signals cannot be unblocked until it's determined that the thread will be allowed to run.
Comment 1 Adhemerval Zanella 2021-05-27 00:32:40 UTC
It was fixed on 2.32 with the strategy of blocking and unblocking signal on pthread_create.

*** This bug has been marked as a duplicate of bug 25098 ***