Look up another CVE · open CVE-2026-74713 in the interactive tracker
CVE-2026-74713
vhost_iotlb: bound map allocation in add_range
Published 2026-08-22 (2 months 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-74713 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 | vulnerable | 6.1.190-1 | No fix published anywhere yet, neither in Debian nor upstream for the series bookworm tracks. Watch the Debian tracker page for this CVE. Advisories for bookworm have historically landed a median of 23 days after publication. |
| Debian 13trixie | vulnerable | 6.12.113-1 | No fix published anywhere yet, neither in Debian nor upstream for the series trixie tracks. Watch the Debian tracker page for this CVE. Advisories for trixie have historically landed a median of 11 days after publication. |
| Debian 14forky | fixed | 7.1.9-1 | Update the kernel and reboot. Fixed in 7.1.9-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.9-1 | Update the kernel and reboot. Fixed in 7.1.9-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
vhost_iotlb_add_range_ctx() only retires an old entry when the table has a non-zero limit, has exactly reached that limit and has VHOST_IOTLB_FLAG_RETIRE set. Non-retiring tables can keep allocating entries after reaching their configured limit. Existing vhost devices allocate their IOTLB with max_iotlb_entries from vhost.c, which defaults to 2048 and is tunable by module parameter. Use the caller-provided limit at the allocation point instead of adding a separate default in the common IOTLB helper, and reject non-positive values in vhost paths that can report an error. Other vhost IOTLB users should not create zero-limit tables when entries can be populated from userspace or guest-controlled requests. Add caller-side max_iotlb_entries parameters for mlx5 vDPA, VDUSE and vhost-vDPA. Reject non-positive VDUSE and vhost-vDPA values, and require at least two entries for vdpa_sim and mlx5 vDPA paths that install full-range mappings, since those mappings are split into two IOTLB entries. Handle full-range mappings in the common helper by checking that the IOTLB can hold both split entries before inserting the first half. This avoids returning an error after leaving a half mapping behind. When the table is full, keep the existing retire behavior for retiring tables and return -ENOSPC for non-retiring tables. Reuse the retired map node instead of freeing it and allocating a replacement, so a stream of IOTLB updates cannot keep forcing GFP_ATOMIC allocations after the table has reached its limit. If a zero-limit IOTLB still reaches the common helper, treat it as a configuration error and return -EINVAL. 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/mlx5/core/mlx5_vdpa.h
drivers/vdpa/mlx5/core/mr.c
drivers/vdpa/mlx5/core/resources.c
drivers/vdpa/vdpa_sim/vdpa_sim.c
drivers/vdpa/vdpa_user/iova_domain.c
drivers/vhost/iotlb.c
drivers/vhost/vdpa.c
drivers/vhost/vhost.c
- What this is
- MELLANOX MLX5 VDPA DRIVERMAINTAINERS section matched on drivers/vdpa/mlx5/ · virtualization@lists.linux.dev · Supported
- Kernel module
- none to look for. The file would have gone into vdpa_sim, and Debian does not compile it into that module, so finding vdpa_sim in lsmod would say nothing about this CVE.
Check it on the machine
grep -wE 'CONFIG_VDPA|CONFIG_VDPA_SIM' /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 4 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, sidn
- n
- not enabled on any flavour - this release does not build the code
- Build switches
- CONFIG_VDPA, CONFIG_VDPA_SIM
- 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-08-22 (2 months ago)source
- CVSS
- 7.1 high
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.14%, higher than 2.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.7 | 6.18.57 | b57164cdddb4 |
| 5.7 | 7.1.9 | ae128dd19040 |
| 5.7 | 7.2 | 1ed35ac7f3fe |
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 flaw is reached via local VHOST_IOTLB_UPDATE writes on /dev/vhost-* or /dev/vhost-vdpa char devices, or when a KVM guest drives virtio IOTLB misses that the VMM resolves through vhost; it is not triggered by remote network packets.
- AC:LAttack complexity, low
- An attacker reliably floods distinct IOTLB mappings by repeatedly issuing VHOST_IOTLB_UPDATE messages or provoking guest IOTLB misses; no race, rare configuration, or attacker-uncontrollable memory layout is required once vhost IOTLB is active.
- PR:NPrivileges required, none
- A malicious KVM guest can provoke unbounded IOTLB growth through normal virtio IOTLB-miss handling without any host credentials; a host attacker holding the vhost-vdpa/vhost device node also needs no capabilities beyond device access.
- UI:NUser interaction, none
- Exploitation requires no victim interaction beyond the VM or vhost device already being in use; the attacker programmatically drives the IOTLB update stream in a tight loop.
- S:CScope, changed
- In cloud/KVM deployments, an unprivileged guest VM causes unbounded host-kernel GFP_ATOMIC allocations in vhost_iotlb_add_range_ctx(), crossing the VM/host security boundary to deny service on the hypervisor.
- C:NConfidentiality impact, none
- The bug causes only unbounded kmalloc of vhost_iotlb_map structures without out-of-bounds access, use-after-free, or information disclosure; successful exploitation does not read kernel memory.
- I:NIntegrity impact, none
- No memory corruption or arbitrary write occurs; impact is limited to kernel memory consumption and does not modify data or enable code execution through the allocation flaw itself.
- A:HAvailability impact, high
- Unbounded IOTLB entry allocation or perpetual GFP_ATOMIC kmalloc when tables are at capacity exhausts kernel memory/atomic reserves, causing host OOM, kernel panics, or complete hypervisor denial of service.