Look up another CVE · open CVE-2026-90009 in the interactive tracker
CVE-2026-90009
scsi: bsg: Fix TOCTOU in io_uring passthrough command setup
Published 2026-09-16 (33 days ago) by the Linux kernel CNA. Subsystem drivers/scsi. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-90009 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | not affected | 6.12.113-1 | Nothing to do. trixie never shipped the vulnerable code. |
| Debian 14forky | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
scsi_bsg_uring_cmd() reads bsg_uring_cmd from the shared mmap'd SQE. Userspace can change a field after we check it and before we use it. request_len is the sharp case: it can grow past sizeof(scmd->cmnd) after the bound check and overflow scmd->cmnd in copy_from_user(). READ_ONCE() the SQE fields we check or use into locals before use.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
drivers/scsi/scsi_bsg.c
- What this is
- SCSI SUBSYSTEMMAINTAINERS section matched on drivers/scsi/ · linux-scsi@vger.kernel.org · Maintained
- Kernel module
- scsi_mod
Check it on the machine
grep -wE 'CONFIG_BLK_DEV_BSG|CONFIG_SCSI' /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w scsi_modPrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this code. Every release below compiles the affected file into the kernels it ships.
- bookworm, trixie, forky, sidb
- b
- built in on some flavours, a module on others
- Build switches
- CONFIG_BLK_DEV_BSG, CONFIG_SCSI
- Reads as
- all on means the file is compiled; any one off means it is not.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-09-16 (33 days ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.17%, higher than 5.4% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- drivers/scsi
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 7.1 | 7.2.5 | f033530105aa |
| 7.1 | 7.3 | 4b3c5965fca9 |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- scsi_bsg_uring_cmd() is reached only via a local io_uring IORING_OP_URING_CMD on a SCSI BSG device node (/dev/bsg/<h:c:i:l>); io_uring and BSG are local syscall/device paths, not a network protocol handler.
- AC:LAttack complexity, low
- The attacker owns both sides of the TOCTOU: one thread submits the uring_cmd while another rewrites request_len in the shared mmap'd SQE. The inline issue path never copies the SQE first, and scsi_alloc_request() sits between the bound check and copy_from_user, making the race attacker-driven and retryable.
- PR:LPrivileges required, low
- bsg_open() has no capability check; access is only DAC on /dev/bsg/* for ordinary SCSI devices. scsi_cmd_allowed() runs after the overflow. Disk/cdrom group membership and uaccess on removable SCSI/USB devices grant this to unprivileged local users without init-namespace root.
- UI:NUser interaction, none
- The attacker opens the BSG node, creates an io_uring ring with SQE128/CQE32, and submits the racing passthrough command themselves; no victim action is required.
- S:UScope, unchanged
- The overflow corrupts the blk-mq scsi_cmnd PDU and adjacent kernel heap in the same host kernel security authority, enabling local privilege escalation rather than a VM, IOMMU, or sandbox boundary crossing.
- C:HConfidentiality impact, high
- copy_from_user() overflows the 32-byte scmd->cmnd into scsi_cmnd pointer fields (sdb, sense_buffer, host_scribble) and adjacent heap with attacker-controlled bytes, which can be groomed into kernel memory disclosure.
- I:HIntegrity impact, high
- The same attacker-controlled heap overflow overwrites kernel pointers and adjacent blk-mq request objects, providing a write primitive exploitable for control-flow hijacking and privilege escalation.
- A:HAvailability impact, high
- A large request_len smash or later use of corrupted scsi_cmnd pointers causes a kernel oops or panic; even a failed copy_from_user still writes through kernel memory until a fault, then frees the corrupted request.