DEBIAN-CVE-2026-74310

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.