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.
Published: 2026-05-01
Score: 7.8 High
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The vulnerability originates in the Linux kernel's GPIB subsystem, where the IOCTL handlers, specifically IBRD, IBWRT, IBCMD, and IBWAIT, use a gpib_descriptor pointer after the big_gpib_mutex lock is released. A competing IBCLOSEDEV ioctl can free that descriptor concurrently, leading to a use‑after‑free (CWE‑911). Based on the description, it is inferred that if an attacker can invoke these IOCTLs on a GPIB device, they potentially can corrupt kernel memory, which may lead to denial of service or local privilege escalation, depending on how the corruption manifests. The fix introduces a descriptor_busy reference count that protects the descriptor during IO operations, preventing the race condition. However, until updated kernels are deployed, systems remain susceptible to this memory corruption flaw.

Affected Systems

All Linux kernel versions that include the GPIB driver are affected; the issue applies to the generic Linux:Linux platform. No specific vendor or version restrictions were provided in the advisory, so any deployment of the GPIB kernel module is considered vulnerable until patched.

Risk and Exploitability

The vulnerability is not listed in CISA KEV and the EPSS score is < 1%, making it difficult to gauge its exploitation probability. Based on the description, it is inferred that the attack vector is local, requiring an attacker to have control over a process that can send IOCTLs to the GPIB device. Based on the description, it is inferred that while the flaw permits kernel memory corruption, no publicly disclosed exploit confirms its impact. Based on the description, it is inferred that given the lack of exploitation data, the risk is considered moderate, but the potential for high impact justifies immediate attention. The CVSS score is 7.8, indicating a high severity.

Generated by OpenCVE AI on May 3, 2026 at 07:50 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Update the Linux kernel to a release that contains the GPIB use‑after‑free fix.
  • If GPIB device support is not required in your environment, unload or disable the gpib kernel module to eliminate the attack surface.
  • Continuously monitor system logs and kernel crash dumps for indications of abnormal GPIB activity or kernel panics that may signal exploitation attempts.

Generated by OpenCVE AI on May 3, 2026 at 07:50 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Sun, 03 May 2026 06:30:00 +0000

Type Values Removed Values Added
Metrics cvssV3_1

{'score': 7.8, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H'}


Sat, 02 May 2026 00:15:00 +0000


Fri, 01 May 2026 14:45:00 +0000

Type Values Removed Values Added
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.
Title gpib: fix use-after-free in IO ioctl handlers
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-05-03T05:45:50.577Z

Reserved: 2026-03-09T15:48:24.140Z

Link: CVE-2026-31769

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Awaiting Analysis

Published: 2026-05-01T15:16:40.090

Modified: 2026-05-03T07:16:20.327

Link: CVE-2026-31769

cve-icon Redhat

Severity :

Publid Date: 2026-05-01T00:00:00Z

Links: CVE-2026-31769 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-05-03T08:00:10Z

Weaknesses