UBUNTU-CVE-2026-74310: Use After Free
In the Linux kernel, the following vulnerability has been resolved: vhost/net: complete zerocopy ubufs only once vhost-net initializes one ubufinfo 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 skbsplit(), which calls skbzerocopyclone() and increments the same ubufinfo refcount. vhostzerocopycomplete() currently treats every ubuf callback as a completed vhost descriptor. It dereferences ubuf->ctx, writes the descriptor completion state, and drops the vhostnetubufref even when the callback only releases a cloned skb reference. A backend reset can therefore wait for and free the vhostnetubufref while another cloned skb still carries the same ubufinfo. A later completion then dereferences the freed ubufs pointer. KASAN reports the stale completion as: BUG: KASAN: slab-use-after-free in vhostzerocopycomplete+0x1d7/0x1f0 BUG: KASAN: slab-use-after-free in vhostzerocopycomplete+0x101/0x1f0 vhostzerocopycomplete skbcopyubufs devforwardskb2 vethxmit The freed object was allocated from vhostnetioctl() while setting the backend and freed through kfreercu()/kvfreercubulk after backend removal, while delayed skb completion still reached vhostzerocopycomplete(). Honor the generic ubufinfo refcount before touching vhost state, and run the vhost descriptor completion only for the final ubuf reference. This matches the msgzerocopycomplete() ownership rule for cloned zerocopy skbs.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 6.8.0-147.147 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 6.8.0-1067.70 - Upgrade
Upgrade
ubuntu/linux-aws-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1013.13~24.04.1 - Upgrade
Upgrade
ubuntu/linux-azureto a version that resolves this vulnerability.Fixed in 6.8.0-1071.79 - Upgrade
Upgrade
ubuntu/linux-azure-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17~24.04.1 - Upgrade
Upgrade
ubuntu/linux-azure-fdeto a version that resolves this vulnerability.Fixed in 6.8.0-1069.76 - Upgrade
Upgrade
ubuntu/linux-azure-fde-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1016.16~24.04.1 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 6.8.0-1071.79 - Upgrade
Upgrade
ubuntu/linux-gcp-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1013.13~24.04.1 - Upgrade
Upgrade
ubuntu/linux-gketo a version that resolves this vulnerability.Fixed in 6.8.0-1066.74 - Upgrade
Upgrade
ubuntu/linux-gkeopto a version that resolves this vulnerability.Fixed in 6.8.0-1052.56 - Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-34.34~24.04.1 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 6.8.0-1067.68 - Upgrade
Upgrade
ubuntu/linux-lowlatencyto a version that resolves this vulnerability.Fixed in 6.8.0-147.147.1 - Upgrade
Upgrade
ubuntu/linux-nvidia-tegrato a version that resolves this vulnerability.Fixed in 6.8.0-1035.38 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 6.8.0-1064.67 - Upgrade
Upgrade
ubuntu/linux-oracle-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1012.12~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-34.34.1~24.04.1 - Upgrade
Upgrade
ubuntu/linux-bluefieldto a version that resolves this vulnerability.Fixed in 6.8.0-1033.38 - Upgrade
Upgrade
ubuntu/linux-realtimeto a version that resolves this vulnerability.Fixed in 6.8.1-1062.63 - Upgrade
Upgrade
ubuntu/linux-aws-fipsto a version that resolves this vulnerability.Fixed in 6.8.0-1067.70+fips1 - Upgrade
Upgrade
ubuntu/linux-azure-fipsto a version that resolves this vulnerability.Fixed in 6.8.0-1071.79+fips1 - Upgrade
Upgrade
ubuntu/linux-fipsto a version that resolves this vulnerability.Fixed in 6.8.0-147.147+fips1 - Upgrade
Upgrade
ubuntu/linux-gcp-fipsto a version that resolves this vulnerability.Fixed in 6.8.0-1071.79+fips1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-34.34 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1013.13 - Upgrade
Upgrade
ubuntu/linux-azureto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-azure-fdeto a version that resolves this vulnerability.Fixed in 7.0.0-1016.16 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1013.13 - Upgrade
Upgrade
ubuntu/linux-gketo a version that resolves this vulnerability.Fixed in 7.0.0-1007.8 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1014.14 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1014.14 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1012.12 - Upgrade
Upgrade
ubuntu/linux-raspito a version that resolves this vulnerability.Fixed in 7.0.0-1020.20 - Upgrade
Upgrade
ubuntu/linux-realtimeto a version that resolves this vulnerability.Fixed in 7.0.0-34.34.1 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-34.34.1 - Compensating control
In vhost/net, honor the generic ubuf_info reference count before accessing vhost state, and run vhost descriptor completion only when releasing the final ubuf reference.
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Ubuntu systems using the listed Linux kernel packages are affected: linux, linux-fips, linux-aws, linux-azure, linux-gcp, and their listed FIPS variants. The vulnerable path involves vhost-net zerocopy transmit handling and a backend socket.
What conditions are needed to trigger the use-after-free?
The condition requires outstanding vhost-net zerocopy TX descriptors whose skb is cloned before all references are released. A backend reset can free the associated vhost reference while a cloned skb still retains the shared ubuf_info, causing a later completion callback to dereference freed memory.
How can an affected system be identified?
Kernel memory-safety diagnostics may report a KASAN slab-use-after-free in vhost_zerocopy_complete. The reported call path can include skb_copy_ubufs, __dev_forward_skb2, and veth_xmit.