The vulnerability in CVE-2026-74310 is a use-after-free in vhost's zerocopy completion path, triggered when skb_zerocopy_clone() — used legitimately by fragmentation paths like batman-adv and container veth forwarding — increments the ubuf_info refcount and produces multiple callbacks for a single descriptor. The callback then finds the vhost_net_ubuf_ref already freed by a backend reset.
The fix checks the refcount before touching vhost state and completes only on the final reference — mechanically trivial, but that triviality is the point. The contract for handling ubuf_info callbacks already existed in msg_zerocopy_complete() in the same kernel tree. vhost didn't diverge from an established pattern; it failed to implement a requirement that was specified from day one. The custom vhost_net_ubuf_ref mechanism with kfree_rcu() was a parallel solution to the same problem, implemented in isolation.
For defenders: verify the patch is applied (the refcount check before vhost state access), then assess whether your workload involves vhost-based virtio-net backends with active zerocopy and any fragmentation-triggering traffic — batman-adv overlays, container-to-host forwarding through veth pairs, or any path that exercises __dev_forward_skb2. The race window is narrow and requires backend reset during active zerocopy transmission, which limits practical exploitability. However, the ubuf_info subsystem is shared across the kernel's entire MSG_ZEROCOPY stack, so the blast radius of a successful exploit extends beyond vhost itself. The CVSS 9.3 reflects that severity; the low EPSS (0.0014) reflects that the specific timing requirements haven't been widely weaponized yet — not that the impact is modest. Prioritize the patch in multi-tenant environments where tenants can influence fragmentation patterns or trigger backend resets.