[Bug 289120] A time-of-check to time-of-use race exists in gpioc_kqread() of GPIO subsystem

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=289120

--- Comment #7 from Qiu-ji Chen <chenqiuji666@gmail.com> ---
(In reply to Ahmad Khalifa from comment #6)

Hi Ahmad,

Thank you for confirming the ioctl race and for the detailed explanation of the
kqueue locking mechanism.

You are absolutely right about knlist_init_mtx; our static analysis and manual
audit completely missed that initialization path. We appreciate the
clarification and will work on improving our tool to correctly handle this
pattern.

Based on your explanation, the expectation is that filterops->f_event will
always be called with the knlist lock held. With this understanding, we
reviewed the call sites in /sys/kern/kern_event.c. We found that while 5 of the
6 calls to f_event do hold the lock, one in knote_fork() appears to be missing
it. In that function, the knlist lock is released at line 573 but not
re-acquired until line 610, leaving the call to kn->kn_fop->f_event(kn,
NOTE_FORK) at line 608 unprotected. Perhaps the lock acquisition at line 610
should be moved before this call?

On a related note, the comment for struct knote in /sys/sys/event.h mentions
that fields like kn_sfflags are protected by the knlist lock, but it doesn't
state that the kn_fop callbacks are also expected to be called under the lock.
It might be helpful to update this comment to make the locking requirement
explicit. So far, I have only audited the call sites for f_event, but it seems
possible that other function pointers in filterops might also have call sites
that violate this locking assumption. I will continue to review them, but
wanted to bring this potential pattern to your attention. In Linux, a tool like
lockdep is very effective for catching these locking violations. I am not
familiar with the equivalent in FreeBSD, but perhaps adding assertions could
help verify the rules.

Thanks again for your time and help.

Best regards,
Qiu-ji Chen

-- 
You are receiving this mail because:
You are the assignee for the bug.