GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel SCSI bsg: TOCTOU on the shared io_uring SQE overflows the SCSI command buffer

CVSS 7.8CVE-2026-90009Kernel, userspace & hypervisorcurated

Impact

scsi_bsg_uring_cmd() reads the bsg_uring_cmd structure straight out of the mmap'd io_uring submission queue entry, which userspace can still write. request_len is validated and then re-read at use time, so it can grow past sizeof(scmd->cmnd) between the bound check and the copy_from_user(), overflowing the SCSI command buffer inside the kernel. That is a controlled kernel heap/stack write reachable from whoever holds the bsg device, which is a straightforward local privilege escalation primitive. On a GPU node that matters wherever SCSI passthrough is handed to a container for storage tooling or enclosure management - a container escape there takes the whole node and every co-tenant pod on it.

Who can reach it

Local. A process that can open a /dev/bsg/* device and submit io_uring passthrough commands - normally root or a container granted that device node. No authentication over the network.

What to do

Take the stable kernel fix that READ_ONCE()s the SQE fields into locals before checking and using them (commits 4b3c5965fca9, f033530105aa). Requires installing the patched kernel and rebooting each node; drain GPU workloads first. Until then, do not expose /dev/bsg/* into containers and keep SCSI generic passthrough restricted to trusted host tooling.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.