https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=289120
--- Comment #5 from Qiu-ji Chen <[email protected]> --- (In reply to Ahmad Khalifa from comment #3) Hi Ahmad, While re-auditing /sys/dev/gpio/gpioc.c, we noticed another potential issue in gpioc_ioctl() under the GPIOCONFIGEVENTS case. There appears to be a Time-of-Check to Time-of-Use (TOCTOU) race condition. The code relies on the !SLIST_EMPTY(&priv->pins) check to prevent races. The assumption seems to be that if the pin list is empty, there can be no concurrent access, since gpioc_read() would return ENXIO and gpioc_interrupt_handler() cannot be invoked if no pins are configured for interrupts. However, since the ioctl interface allows for concurrency, one thread could pass the !SLIST_EMPTY check, while another concurrent ioctl call using GPIOSETCONFIG enables an interrupt pin. This would create a race between the first thread and a now-possible gpioc_interrupt_handler() or gpioc_read(), potentially leading to a Use-After-Free. We suggest protecting the critical section in this ioctl case by holding the priv->mtx lock. Best regards, Qiu-ji Chen -- You are receiving this mail because: You are the assignee for the bug.
