CVE-2026-31769

In the Linux kernel, the following vulnerability has been resolved:

gpib: fix use-after-free in IO ioctl handlers

The IBRD, IBWRT, IBCMD, and IBWAIT ioctl handlers use a gpibdescriptor pointer after board->biggpibmutex has been released. A concurrent IBCLOSEDEV ioctl can free the descriptor via closedev_ioctl() during this window, causing a use-after-free.

The IO handlers (readioctl, writeioctl, commandioctl) explicitly release biggpibmutex before calling their handler. waitioctl() is called with biggpibmutex held, but ibwait() releases it internally when waitmask is non-zero. In all four cases, the descriptor pointer obtained from handleto_descriptor() becomes unprotected.

Fix this by introducing a kernel-only descriptorbusy reference count in struct gpibdescriptor. Each handler atomically increments descriptorbusy under filepriv->descriptorsmutex before releasing the lock, and decrements it when done. closedevioctl() checks descriptorbusy under the same lock and rejects the close with -EBUSY if the count is non-zero.

A reference count rather than a simple flag is necessary because multiple handlers can operate on the same descriptor concurrently (e.g. IBRD and IBWAIT on the same handle from different threads).

A separate counter is needed because ioinprogress can be cleared from unprivileged userspace via the IBWAIT ioctl (through generalibstatus() with setmask containing CMPL), which would allow an attacker to bypass a check based solely on ioinprogress. The new descriptor_busy counter is only modified by the kernel IO paths.

The lock ordering is consistent (biggpibmutex -> descriptorsmutex) and the handlers only hold descriptorsmutex briefly during the lookup, so there is no deadlock risk and no impact on IO throughput.