EUVD-2026-59457
GHSA-8j84-wwj3-jwr4
Severity by source
AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Local access to a vhost-net host is needed (AV:L, PR:L) and exploitation depends on winning a completion-vs-reset race (AC:H); kernel UAF yields high C/I/A, kept scope-unchanged within the kernel.
Primary rating from Vendor (Linux).
CVSS VectorVendor: Linux
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Lifecycle Timeline
5DescriptionCVE.org
In the Linux kernel, the following vulnerability has been resolved:
vhost/net: complete zerocopy ubufs only once
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.
AnalysisAI
Local memory corruption in the Linux kernel's vhost-net driver arises from mishandling of zerocopy TX completion: vhost_zerocopy_complete() treats every ubuf_info callback as a finished vhost descriptor, so when the networking stack clones a zerocopy skb (e.g. batman-adv fragmentation via skb_split/skb_zerocopy_clone, or veth forwarding via skb_copy_ubufs) and a backend reset frees the vhost_net_ubuf_ref, a later delayed completion dereferences the freed ubufs pointer - a slab use-after-free confirmed by KASAN. …
Unlock full vulnerability intelligence
- Risk assessment & exploitation conditions
- Attack chain visualization
- Remediation with exact patch versions
- Threat intelligence from 22 sources
- Personal watchlist & email alerts
Free forever · No credit card required
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata
Vulnerability AssessmentAI
| Exploitation | Requires the host to be running the vhost-net driver with zerocopy TX enabled (experimental_zcopytx), an active zerocopy TX workload that produces outstanding ubuf_info descriptors, and a backend/network path that clones or splits the zerocopy skb before all references drop - concretely batman-adv fragmentation (skb_split → skb_zerocopy_clone) or a forwarding path hitting skb_copy_ubufs (e.g. … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | The signals point to a genuine but not-urgent-for-most bug. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | On a KVM host running vhost-net with zerocopy TX, a local attacker controlling a guest or the host networking configuration drives zerocopy transmits over a backend that clones the skb (for example batman-adv fragmentation or a veth-forwarded path), then races a backend reset/removal so the vhost_net_ubuf_ref is freed while a cloned skb still references the same ubuf_info. When the delayed completion fires, vhost_zerocopy_complete() dereferences the freed pointer, corrupting kernel memory to cause a crash and potentially escalate privileges. … |
| Remediation | Apply the vendor-released kernel patch by upgrading to a fixed stable release for your branch: 6.1.178, 6.6.145, 6.12.97, 6.18.40, or 7.1.5 (mainline fix landed in 7.2-rc1); if you build from source, cherry-pick the corresponding stable commit (e.g. … Detailed patch versions, workarounds, and compensating controls in full report. |
Recommended ActionAI
Within 24 hours, identify all Linux virtualization hosts running vhost-net with zerocopy TX enabled by auditing hypervisor configurations and checking kernel module parameters (verify zerocopy settings via modinfo vhost_net). …
Sign in for detailed remediation steps and compensating controls.
Threat intelligence, references, and detailed analysis are available after sign-in.
Same technique Information Disclosure
View allVendor StatusVendor
Share
External POC / Exploit Code
Leaving vuln.today