Date: Thu, 17 Dec 2020 10:04:16 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 251915] TOCTOU race between tty_signal_sessleader() and killjobc() Message-ID: <bug-251915-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251915 Bug ID: 251915 Summary: TOCTOU race between tty_signal_sessleader() and killjobc() Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: j.piecuch96@gmail.com In tty_signal_sessleader(): if (tp->t_session != NULL && tp->t_session->s_leader != NULL) { p = tp->t_session->s_leader; PROC_LOCK(p); kern_psignal(p, sig); PROC_UNLOCK(p); } We're holding the tty lock, but not the session lock, so the s_leader may be changed to NULL right after the != NULL check by a concurrent invocation of killjobc() by the session leader. The compiler *might* optimize this and only read s_leader a single time, but that's far from guaranteed. I don't have a patch because I'm not sure what the right way to deal with this is. We could read s_leader a single time, like this: if (tp->t_session != NULL && (p = tp->t_session->s_leader) != NULL) { PROC_LOCK(p); kern_psignal(p, sig); PROC_UNLOCK(p); } ...but the compiler may in theory still output vulnerable code. I don't know what assumptions are made in FreeBSD about what compilers can and can't do. -- You are receiving this mail because: You are the assignee for the bug.help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-251915-227>