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/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D251915 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 !=3D NULL && tp->t_session->s_leader !=3D NULL) { p =3D 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 !=3D NULL check by a concurrent invocation = of killjobc() by the session leader. The compiler *might* optimize this and on= ly 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 t= his is. We could read s_leader a single time, like this: if (tp->t_session !=3D NULL && (p =3D tp->t_session->s_leader) !=3D 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. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-251915-227>