Look up another CVE · open CVE-2026-97991 in the interactive tracker
CVE-2026-97991
vdpa_sim_blk: reject out-of-range sector starts
Published 2026-09-25 (24 days ago) by the Linux kernel CNA. Subsystem drivers/vdpa. 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-97991 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.7-1 | Update the kernel and reboot. Fixed in 7.2.7-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.7-1 | Update the kernel and reboot. Fixed in 7.2.7-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
vdpasim_blk_check_range() logs an invalid start sector but continues validating the request. The subsequent unsigned capacity subtraction can underflow and let an out-of-range buffer offset reach the data path. The invalid offset is used by three request paths. VIRTIO_BLK_T_OUT copies guest data to blk->buffer + offset through vringh_iov_pull_iotlb(), causing an out-of-bounds write in _copy_from_iter() or memcpy(). VIRTIO_BLK_T_IN copies from blk->buffer + offset to the guest through vringh_iov_push_iotlb(), causing an out-of-bounds read in _copy_to_iter(). VIRTIO_BLK_T_WRITE_ZEROES passes blk->buffer + offset to memset(), causing an out-of-bounds write. Reject starts at or beyond the capacity before the subtraction. Treat the capacity boundary as invalid because the IN and OUT paths round byte counts down to sectors for validation but later copy the original byte counts. A sub-sector request at the capacity boundary would otherwise still access past the end of the buffer. I found this bug myself, though the patch was written with AI assistance.
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/vdpa/vdpa_sim/vdpa_sim_blk.c
- What this is
- VIRTIO COREMAINTAINERS section matched on drivers/vdpa/ · virtualization@lists.linux.dev · Maintained
- Kernel module
- none to look for. The file would have gone into vdpa_sim_blk, and Debian does not compile it into that module, so finding vdpa_sim_blk in lsmod would say nothing about this CVE.
Check it on the machine
grep -wE 'CONFIG_VDPA|CONFIG_VDPA_SIM|CONFIG_VDPA_SIM_BLOCK' /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_VDPA, CONFIG_VDPA_SIM, CONFIG_VDPA_SIM_BLOCK
- 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-25 (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/vdpa
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 5.13 | 5.15.222 | 2ff2a8d063fd |
| 5.13 | 6.1.189 | 36ef4d8527f7 |
| 5.13 | 6.6.158 | 000c6300776c |
| 5.13 | 6.12.111 | 14acb0d44b7d |
| 5.13 | 6.18.53 | a8a1413a2cfd |
| 5.13 | 7.2.7 | d6dac17e20fd |
| 5.13 | 7.3 | 0a8693f00c40 |
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 bad value is virtio_blk_outhdr.sector, written into the virtqueue by the virtio driver. That driver is a guest VM using the device through vhost-vdpa, or a local process with access to /dev/vhost-vdpa-N. vdpasim_blk_handle_req() reads it with vringh_getdesc_iotlb()/vringh_iov_pull_iotlb(). No network protocol carries it.
- AC:HAttack complexity, high
- The code needs a vdpa_sim_blk device, a test simulator that root must create with VDPA_CMD_DEV_NEW (GENL_ADMIN_PERM) and bind to vhost-vdpa for a VM. The attacker cannot set that up. Once it exists, a single request with a large sector fires the bug every time.
- PR:LPrivileges required, low
- The attacker needs control of the virtqueue driver, for example the guest kernel of a VM that was given the device, or a user granted the vhost-vdpa char device. That is ordinary tenant privilege, not host root.
- UI:NUser interaction, none
- Once the device is assigned, the attacker posts the request on their own virtqueue and the simulator's work function runs vdpasim_blk_handle_req() with no host-side action.
- S:CScope, changed
- The driver of the device (usually a guest VM) corrupts or reads host kernel memory outside blk->buffer. That crosses from the guest's authority into the host kernel's, a guest-to-host boundary.
- C:HConfidentiality impact, high
- VIRTIO_BLK_T_IN with an out-of-range sector makes vringh_iov_push_iotlb() copy from blk->buffer + (sector << 9). The attacker picks that offset from the kvzalloc buffer, and the host kernel memory is returned into the attacker's own descriptors.
- I:HIntegrity impact, high
- VIRTIO_BLK_T_OUT makes vringh_iov_pull_iotlb() copy attacker data to blk->buffer + offset, and WRITE_ZEROES memsets there. The offset is under attacker control, which gives a write into host kernel memory that can lead to code execution.
- A:HAvailability impact, high
- A write or read at a wild offset hits unmapped or critical host memory and oopses or panics the host kernel. That also takes down every other VM on the host.