# CVE-2026-31769: gpib: fix use-after-free in IO ioctl handlers

CVE-2026-31769 is fixed in linux on 1 platform by DEBIAN-CVE-2026-31769 (version 6.19.12-1), released May 15, 2026. It is not reported as exploited. Patch Radar priority: High.

- Web page: https://patchblox.com/security/cve/CVE-2026-31769
- Priority: High
- CVSS: 7.8 (high)
- EPSS: 0.0013
- CISA KEV: not listed
- Exploited (vendor report): no
- Publicly disclosed: no
- Published: May 1, 2026
- Vendor advisory: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-31769

## Description

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 gpib_descriptor pointer after board->big_gpib_mutex has been released.  A concurrent IBCLOSEDEV ioctl can free the descriptor via close_dev_ioctl() during this window, causing a use-after-free.  The IO handlers (read_ioctl, write_ioctl, command_ioctl) explicitly release big_gpib_mutex before calling their handler.  wait_ioctl() is called with big_gpib_mutex held, but ibwait() releases it internally when wait_mask is non-zero.  In all four cases, the descriptor pointer obtained from handle_to_descriptor() becomes unprotected.  Fix this by introducing a kernel-only descriptor_busy reference count in struct gpib_descriptor.  Each handler atomically increments descriptor_busy under file_priv->descriptors_mutex before releasing the lock, and decrements it when done.  close_dev_ioctl() checks descriptor_busy 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 io_in_progress can be cleared from unprivileged userspace via the IBWAIT ioctl (through general_ibstatus() with set_mask containing CMPL), which would allow an attacker to bypass a check based solely on io_in_progress.  The new descriptor_busy counter is only modified by the kernel IO paths.  The lock ordering is consistent (big_gpib_mutex -> descriptors_mutex) and the handlers only hold descriptors_mutex briefly during the lookup, so there is no deadlock risk and no impact on IO throughput.

## Where it's fixed

| Platform | Product | Fixed in | Fix | Released |
|---|---|---|---|---|
| Linux | linux Debian 14 | 6.19.12-1 | [DEBIAN-CVE-2026-31769](https://patchblox.com/security/data/fix/linux/debian-cve-2026-31769.md) | May 15, 2026 |

---

Data as of 2026-11-08T19:12:23Z UTC. Source: Patchblox Patch Radar (https://patchblox.com/security/patch-radar). Patchblox finds out-of-date software on Windows, macOS and Linux and updates it through release rings: https://patchblox.com/demo

Free to use with attribution: show "Data: Patchblox Patch Radar" with a link to https://patchblox.com/security/patch-radar. Terms, including what needs a written agreement: https://patchblox.com/security/patch-radar/use-the-data

Product names, logos and trademarks shown on Patch Radar belong to their respective owners. They are used only to identify the software each security fix applies to and to help readers find their platform. Their use does not imply any affiliation with, or endorsement by, those owners, and Patchblox is not affiliated with any of them.
