Instituto Nacional de ciberseguridad. Sección Incibe
Instituto Nacional de Ciberseguridad. Sección INCIBE-CERT

CVE-2026-31769

Gravedad CVSS v3.1:
ALTA
Tipo:
CWE-416 Utilización después de liberación
Fecha de publicación:
01/05/2026
Última modificación:
11/05/2026

Descripción

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpib: fix use-after-free in IO ioctl handlers<br /> <br /> The IBRD, IBWRT, IBCMD, and IBWAIT ioctl handlers use a gpib_descriptor<br /> pointer after board-&gt;big_gpib_mutex has been released. A concurrent<br /> IBCLOSEDEV ioctl can free the descriptor via close_dev_ioctl() during<br /> this window, causing a use-after-free.<br /> <br /> The IO handlers (read_ioctl, write_ioctl, command_ioctl) explicitly<br /> release big_gpib_mutex before calling their handler. wait_ioctl() is<br /> called with big_gpib_mutex held, but ibwait() releases it internally<br /> when wait_mask is non-zero. In all four cases, the descriptor pointer<br /> obtained from handle_to_descriptor() becomes unprotected.<br /> <br /> Fix this by introducing a kernel-only descriptor_busy reference count<br /> in struct gpib_descriptor. Each handler atomically increments<br /> descriptor_busy under file_priv-&gt;descriptors_mutex before releasing the<br /> lock, and decrements it when done. close_dev_ioctl() checks<br /> descriptor_busy under the same lock and rejects the close with -EBUSY<br /> if the count is non-zero.<br /> <br /> A reference count rather than a simple flag is necessary because<br /> multiple handlers can operate on the same descriptor concurrently<br /> (e.g. IBRD and IBWAIT on the same handle from different threads).<br /> <br /> A separate counter is needed because io_in_progress can be cleared from<br /> unprivileged userspace via the IBWAIT ioctl (through general_ibstatus()<br /> with set_mask containing CMPL), which would allow an attacker to bypass<br /> a check based solely on io_in_progress. The new descriptor_busy<br /> counter is only modified by the kernel IO paths.<br /> <br /> The lock ordering is consistent (big_gpib_mutex -&gt; descriptors_mutex)<br /> and the handlers only hold descriptors_mutex briefly during the lookup,<br /> so there is no deadlock risk and no impact on IO throughput.

Productos y versiones vulnerables

CPE Desde Hasta
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* 6.13 (incluyendo) 6.18.22 (excluyendo)
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* 6.19 (incluyendo) 6.19.12 (excluyendo)
cpe:2.3:o:linux:linux_kernel:7.0:rc1:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc2:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc3:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc4:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc5:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc6:*:*:*:*:*:*