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.
Predictions
Heuristic predictions, AS-IS, for prioritization only.
Mitigations
No mitigations published for this CVE yet.
The vendor-content worker queues fetches as references arrive (check back in a few minutes). Or โ if you've already worked around this in production โ publish your fix to the community-verified tier.
โ Propose a mitigation on Community โ Mitigations published via the community go through AI scoring + 2 human reviewers + 7-day silent objection window before landing here withsource_tier=community-verified.
OS impact
| OS | Version | Status | Fixed in |
|---|---|---|---|
| sles | affected | | |
| debian | bookworm | fixed | 0 |
| debian | bullseye | fixed | 0 |
| debian | forky | fixed | 6.19.12-1 |
| debian | sid | fixed | 6.19.12-1 |
| debian | trixie | fixed | 0 |
| linux-kernel | affected | 6.18.22 | |
| linux-kernel | 7.0 | affected | |
| windows | affected | |
References
- https://git.kernel.org/stable/c/28c75dd143ead62e0dfac564c79d251e21d5d74b
- https://git.kernel.org/stable/c/cae26eff1b56d78bed7873cf3e60a2b1bdd4da6c
- https://git.kernel.org/stable/c/d1857f8296dceb75d00ab857fc3c61bc00c7f5c6
- https://www.suse.com/security/cve/CVE-2026-31769.html
- https://security-tracker.debian.org/tracker/CVE-2026-31769
- https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-31769
CWEs
CWE-416
Community-verified mitigations for this CVE will appear above when contributors publish them.
Verify integrity in audit chain (admin only). AS-IS.