GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux vhost/net: use-after-free when a cloned zerocopy skb completes after backend reset

CVSS 9.3CVE-2026-74310Kernel, userspace & hypervisorcurated

Impact

vhost_zerocopy_complete() treated every ubuf_info callback as a finished vhost descriptor, so when the networking stack cloned a zerocopy TX skb the shared refcount was dropped early. A backend reset can then free the vhost_net_ubuf_ref while a cloned skb still carries the same ubuf_info, and the later completion dereferences freed memory - KASAN reports slab-use-after-free reached through skb_copy_ubufs/veth_xmit. On a GPU node this is a host-side bug in the virtio-net datapath: a guest or container that can drive zerocopy TX and trigger backend changes can crash the hypervisor host, taking every VM and GPU workload on it down with no cheap drain. Reaching it needs a path that clones zerocopy skbs (veth forwarding, or fragmentation as in batman-adv), so it is not triggerable on every configuration; escalation beyond a crash is not established in the record.

Who can reach it

Local - a guest or workload attached to a vhost-net backend that can drive zerocopy transmit while the backend is reset. Only relevant to hosts running KVM guests with vhost-net zerocopy and an skb-cloning egress path; no authentication beyond having the virtio-net interface.

What to do

Take the stable kernel fix (five backport commits listed) and reboot each affected hypervisor host - drain VMs and GPU workloads first. No fixed distro version is given in the record. Live mitigation without a reboot: avoid vhost-net experimental zerocopy (experimental_zcopytx=0) on hosts where it is enabled.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.