CVE-2026-64496

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: event: Fix event FIFO reset race<br /> <br /> `iio_event_getfd()` creates the event file descriptor with<br /> `anon_inode_getfd()`, which allocates a new fd, creates the anonymous<br /> file and installs it in the process fd table before returning to the<br /> caller.<br /> <br /> The IIO code resets the event FIFO after `anon_inode_getfd()` has returned,<br /> but before `IIO_GET_EVENT_FD_IOCTL` has copied the fd number to userspace.<br /> But since fd tables are shared between threads, another thread can guess<br /> the newly allocated fd number and issue a `read()` on it as soon as the fd<br /> has been installed.<br /> <br /> This means the `kfifo_to_user()` in `iio_event_chrdev_read()` can run in<br /> parallel with the `kfifo_reset_out()` in `iio_event_getfd()`.<br /> <br /> The kfifo documentation says that `kfifo_reset_out()` is only safe when it<br /> is called from the reader thread and there is only one concurrent reader.<br /> Otherwise it is dangerous and must be handled in the same way as<br /> `kfifo_reset()`.<br /> <br /> If that happens, `kfifo_to_user()` can advance the FIFO `out` index based<br /> on state from before the reset, after the reset has already moved the `out`<br /> index to the current `in` index. That can leave the FIFO with an `out`<br /> index past the `in` index. A later `read()` can then see an underflowed<br /> FIFO length and copy more data than the event FIFO buffer contains. This<br /> can result in an out-of-bounds read and leak adjacent kernel memory to<br /> userspace.<br /> <br /> Move the FIFO reset before `anon_inode_getfd()`. At that point the event fd is<br /> marked busy, but the new fd has not been installed yet, so userspace cannot<br /> access it while the FIFO is reset.