Back to CVE records
Critical 9.3Published Aug 15, 2026

CVE-2026-74310vhost/net: complete zerocopy ubufs only once

Updated under an hour ago ()

Does this affect you?

It affects Linux. Add what you run to find out whether that includes you.

No exploitation reported and no EPSS estimate yet.

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.

CVSS
9.3 CRITICAL (v3.1, CNA)CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Weakness (CWE)
Not given
Known exploited
Not in CISA's KEV catalog
EPSS (exploitation in the next 30 days)
Not loaded for this CVE
Assigned by
Linux
NVD analysis
Received
Record last updated
Oct 16, 2026
First seen by InfoSec Signals
Oct 9, 2026

Affected products

Affected products
Linux Linux
linux:linux (from the name)
from bab632d69ee48a106e779b60cc01adfe80a72807 before ea71f873423fb73e66ad88936d6759ac0ad4aa53; from bab632d69ee48a106e779b60cc01adfe80a72807 before 6445b945024f4c7675ae5352b2d5885cb1deea71; from bab632d69ee48a106e779b60cc01adfe80a72807 before a9f8a1d2e3ff511eafd4c5462481950c2f4d2b5d; from bab632d69ee48a106e779b60cc01adfe80a72807 before 321c73baf54d971ce3771fea275c98a247f7ee35; from bab632d69ee48a106e779b60cc01adfe80a72807 before c069437924663539a93a1e5afe90838d9ccee284; from bab632d69ee48a106e779b60cc01adfe80a72807 before 8f6898fe80794f2d7c3d38c1158c806e4074a1c4
CNA record

References

The CVE record is authoritative. Products marked “from the name” were identified from the CNA's free-text names, not a CPE, and are matched less certainly. This product uses the NVD API but is not endorsed or certified by the NVD.

Your cookie choices
We use essential cookies to run this site, and, only with your consent, an advertising cookie from Google to measure whether our ads lead to sign-ups and subscriptions. See our for details.