{"id":"CVE-2026-31769","summary":"gpib: fix use-after-free in IO ioctl handlers","details":"In the Linux kernel, the following vulnerability has been resolved:\n\ngpib: fix use-after-free in IO ioctl handlers\n\nThe IBRD, IBWRT, IBCMD, and IBWAIT ioctl handlers use a gpib_descriptor\npointer after board-\u003ebig_gpib_mutex has been released.  A concurrent\nIBCLOSEDEV ioctl can free the descriptor via close_dev_ioctl() during\nthis window, causing a use-after-free.\n\nThe IO handlers (read_ioctl, write_ioctl, command_ioctl) explicitly\nrelease big_gpib_mutex before calling their handler.  wait_ioctl() is\ncalled with big_gpib_mutex held, but ibwait() releases it internally\nwhen wait_mask is non-zero.  In all four cases, the descriptor pointer\nobtained from handle_to_descriptor() becomes unprotected.\n\nFix this by introducing a kernel-only descriptor_busy reference count\nin struct gpib_descriptor.  Each handler atomically increments\ndescriptor_busy under file_priv-\u003edescriptors_mutex before releasing the\nlock, and decrements it when done.  close_dev_ioctl() checks\ndescriptor_busy under the same lock and rejects the close with -EBUSY\nif the count is non-zero.\n\nA reference count rather than a simple flag is necessary because\nmultiple handlers can operate on the same descriptor concurrently\n(e.g. IBRD and IBWAIT on the same handle from different threads).\n\nA separate counter is needed because io_in_progress can be cleared from\nunprivileged userspace via the IBWAIT ioctl (through general_ibstatus()\nwith set_mask containing CMPL), which would allow an attacker to bypass\na check based solely on io_in_progress.  The new descriptor_busy\ncounter is only modified by the kernel IO paths.\n\nThe lock ordering is consistent (big_gpib_mutex -\u003e descriptors_mutex)\nand the handlers only hold descriptors_mutex briefly during the lookup,\nso there is no deadlock risk and no impact on IO throughput.","modified":"2026-07-08T08:06:22.115100095Z","published":"2026-05-01T14:14:58.617Z","database_specific":{"cna_assigner":"Linux","osv_generated_from":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/31xxx/CVE-2026-31769.json"},"references":[{"type":"WEB","url":"https://git.kernel.org/stable/c/28c75dd143ead62e0dfac564c79d251e21d5d74b"},{"type":"WEB","url":"https://git.kernel.org/stable/c/cae26eff1b56d78bed7873cf3e60a2b1bdd4da6c"},{"type":"WEB","url":"https://git.kernel.org/stable/c/d1857f8296dceb75d00ab857fc3c61bc00c7f5c6"},{"type":"ADVISORY","url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/31xxx/CVE-2026-31769.json"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31769"},{"type":"PACKAGE","url":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"}],"affected":[{"ranges":[{"type":"GIT","repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","events":[{"introduced":"9dde4559e93955ccc47d588f7fd051684d55c4e7"},{"fixed":"cae26eff1b56d78bed7873cf3e60a2b1bdd4da6c"},{"fixed":"28c75dd143ead62e0dfac564c79d251e21d5d74b"},{"fixed":"d1857f8296dceb75d00ab857fc3c61bc00c7f5c6"}]}],"database_specific":{"source":"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-31769.json"}},{"package":{"name":"Kernel","ecosystem":"Linux"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"6.13.0"},{"fixed":"6.18.22"}]},{"type":"ECOSYSTEM","events":[{"introduced":"6.19.0"},{"fixed":"6.19.12"}]}],"database_specific":{"source":"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-31769.json"}}],"schema_version":"1.7.5","severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"}]}