Answer in brief
CVE-2026-74310 records a Critical severity (CVSS 9.3) vulnerability in vhost/net: complete zerocopy ubufs only once. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 9.3. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=bab632d69ee48a106e779b60cc01adfe80a72807 <ea71f873423fb73e66ad88936d6759ac0ad4aa53 || >=bab632d69ee48a106e779b60cc01adfe80a72807 <6445b945024f4c7675ae5352b2d5885cb1deea71 || >=bab632d69ee48a106e779b60cc01adfe80a72807 <a9f8a1d2e3ff511eafd4c5462481950c2f4d2b5d || >=bab632d69ee48a106e779b60cc01adfe80a72807 <321c73baf54d971ce3771fea275c98a247f7ee35 || >=bab632d69ee48a106e779b60cc01adfe80a72807 <c069437924663539a93a1e5afe90838d9ccee284 || >=bab632d69ee48a106e779b60cc01adfe80a72807 <8f6898fe80794f2d7c3d38c1158c806e4074a1c4 | ea71f873423fb73e66ad88936d6759ac0ad4aa53, 6445b945024f4c7675ae5352b2d5885cb1deea71, a9f8a1d2e3ff511eafd4c5462481950c2f4d2b5d, 321c73baf54d971ce3771fea275c98a247f7ee35, c069437924663539a93a1e5afe90838d9ccee284, 8f6898fe80794f2d7c3d38c1158c806e4074a1c4 |
| Linux/Linuxgeneric | 3.1 | Not reported |
Published upstream
Aug 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 17, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 15, 2026
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.
Quoted source text, attributed separately from HOL analysis.