CVE-2026-31769
Awaiting Analysis Awaiting Analysis - Queue
Use-After-Free in Linux Kernel GPIB Subsystem

Publication date: 2026-05-01

Last updated on: 2026-05-03

Assigner: kernel.org

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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-05-01
Last Modified
2026-05-03
Generated
2026-05-07
AI Q&A
2026-05-01
EPSS Evaluated
2026-05-05
NVD
CVE-2026-31769
EUVD
EUVD-2026-26582
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability is a use-after-free issue in the Linux kernel's gpib driver, specifically in its IO ioctl handlers (IBRD, IBWRT, IBCMD, and IBWAIT). These handlers use a pointer to a gpib_descriptor after releasing a mutex (big_gpib_mutex), which can lead to the descriptor being freed concurrently by another ioctl call (IBCLOSEDEV). This results in the handlers accessing memory that has already been freed, causing a use-after-free condition.

The problem arises because the descriptor pointer becomes unprotected after the mutex is released, allowing a race condition where the descriptor can be freed while still in use. The fix involves adding a kernel-only reference count (descriptor_busy) to track active uses of the descriptor, preventing it from being freed while in use by rejecting close operations if the descriptor is busy.


How can this vulnerability impact me? :

This use-after-free vulnerability can lead to undefined behavior in the kernel, including potential crashes, memory corruption, or escalation of privileges. An attacker could exploit this race condition to cause denial of service or possibly execute arbitrary code within the kernel context, compromising system stability and security.


What immediate steps should I take to mitigate this vulnerability?

The vulnerability has been fixed in the Linux kernel by introducing a kernel-only descriptor_busy reference count to prevent use-after-free conditions in gpib ioctl handlers.

To mitigate this vulnerability immediately, you should update your Linux kernel to a version that includes this fix.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart