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 Vector: CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
CVSS Score: 9.3
AV:L - The bug is only reachable on the vhost-net TX zerocopy path via /dev/vhost-net ioctls or virtio-net TX descriptors handled by the host vhost worker; remote wire packets do not carry vhost ubuf_info state, so no network-facing host protocol reaches vhost_zerocopy_complete().
AC:L - Once experimental_zcopytx is enabled, an attacker can reliably send >=256-byte zerocopy TX frames through a tap/veth backend so skb_zerocopy_clone/skb_copy_ubufs fires, then force backend teardown via VHOST_NET_SET_BACKEND or VM stop/migration while cloned completions remain pending.
PR:N - A malicious KVM guest on a host using vhost-net needs no host root, capabilities, or /dev/vhost-net access—only control of virtio TX descriptors and normal VM networking; a host-side attacker can also open /dev/vhost-net with only device-node permissions because drivers/vhost performs no capable() checks.
UI:N - No victim user interaction is required beyond standard VM or vhost-net operation; the attacker directly drives virtio TX traffic, optional veth forwarding that clones zerocopy skbs, and backend reset/teardown that frees vhost_net_ubuf_ref while stale ubuf completions are still outstanding.
S:C - In the standard KVM deployment, vhost-net is host-kernel code enforcing the guest NIC boundary; the slab use-after-free in vhost_zerocopy_complete executes in host context from guest-supplied zerocopy TX, corrupting host vhost/virtqueue state outside the guest security authority.
C:H - This is a slab use-after-free: after premature completion frees vhost_net_ubuf_ref, a later skb_zcopy_clear callback dereferences freed ubuf->ctx/ubufs memory in vhost_zerocopy_complete, giving attacker-influenced UAF primitives suitable for arbitrary kernel memory disclosure.
I:H - The stale completion writes vq->heads[ubuf->desc].len and decrements vhost_net_ubuf_ref on freed structures; UAF heap corruption of this class is leveragable into arbitrary write and host control-flow hijacking, including potential VM-to-host privilege escalation.
A:H - KASAN reports slab-use-after-free in vhost_zerocopy_complete during skb_copy_ubufs/veth_xmit completion; this readily causes host kernel oops or panic and can be retriggered from a virtio guest TX loop or repeated backend resets until the host or hypervisor is unavailable.
| Attack Vector |
Local |
Scope |
Changed |
| Attack Complexity |
Low |
Confidentiality Impact |
High |
| Privileges Required |
None |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
High |
AV:L - The bug is only reachable on the vhost-net TX zerocopy path via /dev/vhost-net ioctls or virtio-net TX descriptors handled by the host vhost worker; remote wire packets do not carry vhost ubuf_info state, so no network-facing host protocol reaches vhost_zerocopy_complete().
AC:L - Once experimental_zcopytx is enabled, an attacker can reliably send >=256-byte zerocopy TX frames through a tap/veth backend so skb_zerocopy_clone/skb_copy_ubufs fires, then force backend teardown via VHOST_NET_SET_BACKEND or VM stop/migration while cloned completions remain pending.
PR:N - A malicious KVM guest on a host using vhost-net needs no host root, capabilities, or /dev/vhost-net access—only control of virtio TX descriptors and normal VM networking; a host-side attacker can also open /dev/vhost-net with only device-node permissions because drivers/vhost performs no capable() checks.
UI:N - No victim user interaction is required beyond standard VM or vhost-net operation; the attacker directly drives virtio TX traffic, optional veth forwarding that clones zerocopy skbs, and backend reset/teardown that frees vhost_net_ubuf_ref while stale ubuf completions are still outstanding.
S:C - In the standard KVM deployment, vhost-net is host-kernel code enforcing the guest NIC boundary; the slab use-after-free in vhost_zerocopy_complete executes in host context from guest-supplied zerocopy TX, corrupting host vhost/virtqueue state outside the guest security authority.
C:H - This is a slab use-after-free: after premature completion frees vhost_net_ubuf_ref, a later skb_zcopy_clear callback dereferences freed ubuf->ctx/ubufs memory in vhost_zerocopy_complete, giving attacker-influenced UAF primitives suitable for arbitrary kernel memory disclosure.
I:H - The stale completion writes vq->heads[ubuf->desc].len and decrements vhost_net_ubuf_ref on freed structures; UAF heap corruption of this class is leveragable into arbitrary write and host control-flow hijacking, including potential VM-to-host privilege escalation.
A:H - KASAN reports slab-use-after-free in vhost_zerocopy_complete during skb_copy_ubufs/veth_xmit completion; this readily causes host kernel oops or panic and can be retriggered from a virtio guest TX loop or repeated backend resets until the host or hypervisor is unavailable.
CVSS 3.1