[SRU][N:hwe-6.17/N][PATCH 0/2] CVE-2026-53365

Cengiz Can cengiz.can at canonical.com
Fri Sep 11 08:17:42 UTC 2026


https://ubuntu.com/security/CVE-2026-53365

[ Impact ]

In the Linux kernel, the following vulnerability has been resolved:

vsock/virtio: fix zerocopy completion for multi-skb sends

When a large message is fragmented into multiple skbs, the zerocopy uarg is
only allocated and attached to the last skb in the loop. Non-final skbs carry
pinned user pages with no completion tracking, so the kernel has no way to
notify userspace when those pages are safe to reuse. If the loop breaks early
the uarg is never allocated at all, leaking pinned pages with no completion
notification.

Fix this by following the approach used by TCP: allocate the zerocopy uarg (if
not provided by the caller) before the send loop and attach it to every skb via
skb_zcopy_set(), which takes a reference per skb. Each skb's completion
properly decrements the refcount, and the notification only fires after the
last skb is freed. On failure, if no data was sent, the uarg is cleanly aborted
via net_zcopy_put_abort().

This issue was initially discovered by sashiko while reviewing commit
1cb36e252211 ("vsock/virtio: fix MSG_ZEROCOPY pinned-pages accounting") but was
pre-existing.

[ Fix ]

noble/linux-hwe-6.17: backported from ae38d9179190
noble/linux: backported from ae38d9179190

[ Test Plan ]

Build and boot tested.

[ Where Problems Could Occur ]

A bad fix in this area would affect systems using AF_VSOCK over the virtio
transport with MSG_ZEROCOPY sends, primarily virtual machine guests and hosts
that exchange large messages over vsock; a regression could show up as stalled
or missing zerocopy completion notifications or as mishandled pinned user
pages. Systems that do not use vsock, or that use vsock without the
MSG_ZEROCOPY flag, are not affected by this change.

[ Other Info ]

Kybele flow-v11-25-ga27c0fa6. Reference: 557e55fa/v1



More information about the kernel-team mailing list