Look up another CVE · open CVE-2026-74310 in the interactive tracker
CVE-2026-74310
vhost/net: complete zerocopy ubufs only once
Published 2026-08-15 (2 months 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-74310 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 | fixed | 6.1.180-1 | Update the kernel and reboot. Fixed in 6.1.180-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixed | 6.12.100-1 | Update the kernel and reboot. Fixed in 6.12.100-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.1.5-1 | Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.5-1 | Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
vhost-net initializes one ubuf_info per outstanding zerocopy TX descriptor and hands it to the backend socket. The networking stack may then clone a zerocopy skb before all skb references are released. For example, batman-adv fragmentation reaches skb_split(), which calls skb_zerocopy_clone() and increments the same ubuf_info refcount. vhost_zerocopy_complete() currently treats every ubuf callback as a completed vhost descriptor. It dereferences ubuf->ctx, writes the descriptor completion state, and drops the vhost_net_ubuf_ref even when the callback only releases a cloned skb reference. A backend reset can therefore wait for and free the vhost_net_ubuf_ref while another cloned skb still carries the same ubuf_info. A later completion then dereferences the freed ubufs pointer. KASAN reports the stale completion as: BUG: KASAN: slab-use-after-free in vhost_zerocopy_complete+0x1d7/0x1f0 BUG: KASAN: slab-use-after-free in vhost_zerocopy_complete+0x101/0x1f0 vhost_zerocopy_complete skb_copy_ubufs __dev_forward_skb2 veth_xmit The freed object was allocated from vhost_net_ioctl() while setting the backend and freed through kfree_rcu()/kvfree_rcu_bulk after backend removal, while delayed skb completion still reached vhost_zerocopy_complete(). Honor the generic ubuf_info refcount before touching vhost state, and run the vhost descriptor completion only for the final ubuf reference. This matches the msg_zerocopy_complete() ownership rule for cloned zerocopy skbs.
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/net.c
- What this is
- VIRTIO HOST (VHOST)MAINTAINERS section matched on drivers/vhost/ · kvm@vger.kernel.org · Maintained
- Kernel module
- none to look for. The file would have gone into vhost_net, and Debian does not compile it into that module, so finding vhost_net in lsmod would say nothing about this CVE.
Check it on the machine
grep -wE 'CONFIG_VHOST|CONFIG_VHOST_IOTLB|CONFIG_VHOST_NET|CONFIG_VHOST_RING' /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_VHOST, CONFIG_VHOST_IOTLB, CONFIG_VHOST_NET, CONFIG_VHOST_RING
- 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-15 (2 months ago)source
- CVSS
- 9.3 critical
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/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/vhost
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 3.1 | 6.1.178 | ea71f873423f |
| 3.1 | 6.6.145 | 6445b945024f |
| 3.1 | 6.12.97 | a9f8a1d2e3ff |
| 3.1 | 6.18.40 | 321c73baf54d |
| 3.1 | 7.1.5 | c06943792466 |
| 3.1 | 7.2 | 8f6898fe8079 |
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 bug is only reachable on the vhost-net TX zerocopy path via /dev/vhost-net ioctls or virtio-net TX descriptors handled by the host vhost worker; remote wire packets do not carry vhost ubuf_info state, so no network-facing host protocol reaches vhost_zerocopy_complete().
- AC:LAttack complexity, low
- Once experimental_zcopytx is enabled, an attacker can reliably send >=256-byte zerocopy TX frames through a tap/veth backend so skb_zerocopy_clone/skb_copy_ubufs fires, then force backend teardown via VHOST_NET_SET_BACKEND or VM stop/migration while cloned completions remain pending.
- PR:NPrivileges required, none
- A malicious KVM guest on a host using vhost-net needs no host root, capabilities, or /dev/vhost-net access—only control of virtio TX descriptors and normal VM networking; a host-side attacker can also open /dev/vhost-net with only device-node permissions because drivers/vhost performs no capable() checks.
- UI:NUser interaction, none
- No victim user interaction is required beyond standard VM or vhost-net operation; the attacker directly drives virtio TX traffic, optional veth forwarding that clones zerocopy skbs, and backend reset/teardown that frees vhost_net_ubuf_ref while stale ubuf completions are still outstanding.
- S:CScope, changed
- In the standard KVM deployment, vhost-net is host-kernel code enforcing the guest NIC boundary; the slab use-after-free in vhost_zerocopy_complete executes in host context from guest-supplied zerocopy TX, corrupting host vhost/virtqueue state outside the guest security authority.
- C:HConfidentiality impact, high
- This is a slab use-after-free: after premature completion frees vhost_net_ubuf_ref, a later skb_zcopy_clear callback dereferences freed ubuf->ctx/ubufs memory in vhost_zerocopy_complete, giving attacker-influenced UAF primitives suitable for arbitrary kernel memory disclosure.
- I:HIntegrity impact, high
- The stale completion writes vq->heads[ubuf->desc].len and decrements vhost_net_ubuf_ref on freed structures; UAF heap corruption of this class is leveragable into arbitrary write and host control-flow hijacking, including potential VM-to-host privilege escalation.
- A:HAvailability impact, high
- KASAN reports slab-use-after-free in vhost_zerocopy_complete during skb_copy_ubufs/veth_xmit completion; this readily causes host kernel oops or panic and can be retriggered from a virtio guest TX loop or repeated backend resets until the host or hypervisor is unavailable.