public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "bugdal at aerifal dot cx" <sourceware-bugzilla@sourceware.org> To: glibc-bugs@sources.redhat.com Subject: [Bug libc/14750] New: Race condition in posix_spawn vfork usage vs signal handlers Date: Sun, 21 Oct 2012 20:42:00 -0000 [thread overview] Message-ID: <bug-14750-131@http.sourceware.org/bugzilla/> (raw) http://sourceware.org/bugzilla/show_bug.cgi?id=14750 Bug #: 14750 Summary: Race condition in posix_spawn vfork usage vs signal handlers Product: glibc Version: unspecified Status: NEW Severity: normal Priority: P2 Component: libc AssignedTo: unassigned@sourceware.org ReportedBy: bugdal@aerifal.cx CC: drepper.fsp@gmail.com Classification: Unclassified When posix_spawn uses vfork, it does not block signals. This allows the parent process's signal handlers to get invoked in the child process, corrupting the parent process's state. For example: 1. Memory state will be as if the signal handler ran, but other state such as signal dispositions, open files, etc. modified from the signal handler will not be reflected in the parent. 2. The same signal (assuming the signal was sent to an entire process-group, which is the main way a signal could arrive in the new child) may be processed twice in the context of the parent process's memory space. 3. Properties of the child process (e.g. its pid) may end up stored in the parent process's address space. These are just a few examples; there should be plenty more ways things can go wrong. To fix the problem, the vfork/exec process needs to follow the steps below: 1. Mask all signals (including NPTL-internal ones) 2. vfork 3. In child, reset all signal dispositions to SIG_DFL unless the existing disposition is SIG_IGN. 4. In child, restore the original signal mask. 5. In child, finish up and exec/_exit. 6. In parent, restore the original signal mask. Note that step 3 would happen in kernelspace as part of exec anyway, but it must be done explicitly in userspace to make it safe to unmask signals. As an alternative, restoring the signal mask, and all of the post-fork work of posix_spawn, could be outsourced to an external program, i.e. first exec $prefix/libexec/posix_spawn, which would restore signals, perform the file actions, etc. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
next reply other threads:[~2012-10-21 20:42 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-10-21 20:42 bugdal at aerifal dot cx [this message] 2014-02-10 21:22 ` [Bug libc/14750] " sionescu+BugTrackers at cddr dot org 2014-02-11 21:34 ` bugdal at aerifal dot cx 2014-06-25 6:43 ` fweimer at redhat dot com 2014-09-20 4:11 ` carlos at redhat dot com 2020-07-28 7:03 ` meave390 at gmail dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-14750-131@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@sources.redhat.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).