High [CVE-2026-53365] fix zerocopy completion for multi-skb sends
This high-severity Red Hat Linux advisory covers CVE-2026-53365 affecting Red Hat Enterprise Linux 10, Red Hat Enterprise Linux 9, Red Hat package: kernel-rt.
Android app · Google Play
Monitor future Red Hat Linux CVEs from your phone.
Choose a whole vendor or a precise platform, then receive matching security advisories by phone notification, email, or both. Coverage follows 32 official vendor sources and 160+ reviewed platform categories.
Summary
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.
An issue in how user arguments (uargs) are handled for these buffers can lead to pinned user pages not being properly tracked or released.
Affected products named by the advisory: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 9; Red Hat package: kernel-rt.
Affected versions
No affected-version range was extracted from the source record. The vendor advisory is authoritative — check it before change work.
Official advisory · high-confidence parse· fetched 6 days ago·verify at source
Fixed versions
No fixed release is recorded yet. That does not prove no patch exists — confirm against the vendor advisory.
Official advisory · high-confidence parse· fetched 6 days ago·verify at source
Mitigation checklist
- The vulnerable code path is only reachable when using virtio-vsock with zerocopy transmit on virtual machines using the vhost-vsock or virtio-vsock transport. Systems that do not use VM socket communication (AF_VSOCK) are not affected. To prevent the vulnerable code path from being reached, the vhost_vsock kernel module can be unloaded and blacklisted if vsock functionality is not required: ``` modprobe -r vhost_vsock echo "blacklist vhost_vsock" > /etc/modprobe.d/vsock-blacklist.conf ``` Systems that rely on VM-to-host socket communication (e.g., QEMU guest agent communication) cannot use this mitigation and should prioritize applying the kernel fix.
Official advisory · high-confidence parse· fetched 6 days ago·verify at source
Discussion(0)
No comments yet. Share field notes, upgrade gotchas, or questions — verify against the vendor advisory before acting on community advice.
Sign in to join the discussion.