Look up another CVE · open CVE-2026-93782 in the interactive tracker
CVE-2026-93782
vhost-scsi: flush backend after device ioctls
Published 2026-09-24 (24 days ago) by the Linux kernel CNA. Subsystem drivers/vhost. Debian urgency: not yet assigned.
Debian does not build this code. The per-release build detail is under "Where it lives" below.
What to do, per Debian release
Debian's own status for CVE-2026-93782 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 | fixedDLA-4841-1 · 2026-10-17 · text | 6.1.190-1 | Update the kernel and reboot. DLA-4841-1 shipped the fix on 2026-10-17, in 6.1.190-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixedDSA-6528-1 · 2026-09-29 · text | 6.12.111-1 | Update the kernel and reboot. DSA-6528-1 shipped the fix on 2026-09-29, in 6.12.111-1. A running kernel keeps the old code until the machine restarts. |
| 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. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4817-1 · 2026-10-04 · text | 6.12.111-1~deb12u1 | Update the kernel and reboot. DLA-4817-1 shipped the fix on 2026-10-04, in 6.12.111-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
vhost-scsi translates guest response descriptors into userspace iovecs when commands are submitted. Target-core completes those commands asynchronously, so VHOST_SET_MEM_TABLE can replace the memory table while an in-flight command still retains response iovecs translated through the old table. If the old mapping is reused after VHOST_SET_MEM_TABLE returns, command completion can write the response to an unrelated userspace object. Flush the vhost-scsi backend after vhost_dev_ioctl() handles a device ioctl. This waits for in-flight commands that can still use the old response iovecs before the ioctl returns.
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/vhost/scsi.c
- What this is
- VIRTIO HOST (VHOST-SCSI)MAINTAINERS section matched on drivers/vhost/scsi.c · virtualization@lists.linux.dev · Maintained
- Kernel module
- none to look for. The file would have gone into vhost_scsi, and Debian does not compile it into that module, so finding vhost_scsi in lsmod would say nothing about this CVE.
Check it on the machine
grep -wE 'CONFIG_VHOST|CONFIG_VHOST_IOTLB|CONFIG_VHOST_RING|CONFIG_VHOST_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.
Show whether Debian builds this, per release
Debian does not build this code. In 5 releases below, every kernel flavour Debian publishes has the switch off, so the vulnerable file is compiled into no kernel binary Debian ships.
- bookworm, trixie, forky, sid, bookworm · linux-6.12n
- n
- not enabled on any flavour - this release does not build the code
- Build switches
- CONFIG_VHOST, CONFIG_VHOST_IOTLB, CONFIG_VHOST_RING, CONFIG_VHOST_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-24 (24 days ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.12%, higher than 1.8% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- drivers/vhost
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 3.6 | 5.10.271 | 6436411203d8 |
| 3.6 | 5.15.222 | cec088285adc |
| 3.6 | 6.1.189 | e0bf6bed5286 |
| 3.6 | 6.6.158 | be2636e1b21f |
| 3.6 | 6.12.111 | 981c97d09c6b |
| 3.6 | 6.18.53 | 6c1b802e36b0 |
| 3.6 | 7.2 | 22598f55a4c2 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4841-1 | 2026-10-17 | bookworm 6.1.190-1 | tracker |
| DLA-4817-1 | 2026-10-04 | bookworm 6.12.111-1~deb12u1 | tracker |
| DSA-6528-1 | 2026-09-29 | trixie 6.12.111-1 | tracker |
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
- The missing flush is in vhost_scsi_ioctl() after vhost_dev_ioctl() handles VHOST_SET_MEM_TABLE via vhost_set_memory() on /dev/vhost-scsi; the retained pointers are tvc_resp_iovs filled by vhost_scsi_setup_resp_iovs() from vhost_get_vq_desc() on the local virtio-scsi virtqueue, not a network PDU.
- AC:HAttack complexity, high
- A guest can leave commands in target-core via vhost_scsi_handle_vq()->vhost_scsi_target_queue_cmd()->target_submit(), but cannot call VHOST_SET_MEM_TABLE; only the VMM issues that ioctl (memory hotplug or live migration), so the replacement that makes old HVAs reusable is outside the attacker's control.
- PR:LPrivileges required, low
- The attacker is a VM tenant sending virtio-scsi I/O that plants those tvc_resp_iovs; vhost_scsi_open() and vhost_scsi_ioctl() have no capable() check, and the already-attached LIO tpg (VHOST_SCSI_SET_ENDPOINT by QEMU) lets that guest I/O run without host root.
- UI:NUser interaction, none
- The guest plants in-flight commands by kicking its own virtqueue; no other user must mount an image or open a file. A later VMM VHOST_SET_MEM_TABLE is ordinary hypervisor memory-listener bookkeeping, not a tricked interactive action.
- S:CScope, changed
- vhost_scsi_complete_cmd_work() copy_to_iter()s virtio_scsi_cmd_resp through stale tvc_resp_iovs (and vhost_scsi_copy_sgl_to_iov() through a stale read_iter) into the host QEMU mm, so guest-originated completion corrupts VMM userspace across the KVM guest-to-host boundary.
- C:HConfidentiality impact, high
- After QEMU reuses the old HVA, completion writes into unrelated VMM objects; the copied_iov READ path (vhost_scsi_copy_iov_to_sgl() dup_iter, then vhost_scsi_copy_sgl_to_iov()) can copy LUN data into that remapped heap, which is leverageable to disclose host memory back to the guest.
- I:HIntegrity impact, high
- copy_to_iter() of the packed virtio_scsi_cmd_resp plus, when vhost_scsi_map_to_sgl() falls back to vhost_scsi_copy_iov_to_sgl() for misaligned I/O with sgl_count>BIO_MAX_VECS, a guest-influenced READ payload into the remapped HVA, corrupting QEMU heap objects and enabling VMM control-flow hijack.
- A:HAvailability impact, high
- A reused QEMU mapping hit by that completion write corrupts VMM heap metadata and aborts QEMU, terminating the VM; an unmapped old HVA only hits the "Faulted on virtio_scsi_cmd_resp" path, but reuse after VHOST_SET_MEM_TABLE is the contract the ioctl was supposed to guarantee.