Summary
VsockDrop (CVE-2026-53365) is a local privilege escalation flaw in the Linux kernel's virtio vsock zerocopy send path. When a large MSG_ZEROCOPY send fragments across several socket buffers, only the last buffer carries the completion object the release path expects, so the kernel drops a page reference it never took. Combined with io_uring registered buffers, this frees a still-pinned page that gets reclaimed as page cache for /usr/bin/su, letting an ordinary unprivileged local user rewrite the interpreter path and reach root. No hypervisor, guest, or virtual machine is required — the vsock_loopback transport (VMADDR_CID_LOCAL) lets a process talk to itself locally. Scored 5.5 (Red Hat Moderate), but a working public exploit has been released.
Affected Platforms
Upstream, Linux kernels from 6.7 onward that have not taken the fix are affected.
- Ubuntu 24.04 (6.8 GA and 6.17 HWE, plus AWS/Azure/GCP/GKE variants): vulnerable, no Canonical fix released.
- Ubuntu 22.04 with HWE 6.8: vulnerable, no Canonical fix released.
- Ubuntu 26.04 and the 24.04 HWE 7.0 line: vulnerable, fixes in progress.
- RHEL 9 and 10, including the AlmaLinux, Rocky, Oracle and CloudLinux rebuilds: vulnerable code present, no vendor fix, but the public exploit is blocked as shipped by the io_uring default (kernel.io_uring_disabled = 2).
- Debian 13 trixie: fixed via DSA-6405-1 (original 6.12 release was vulnerable).
- Debian 12 bookworm on the optional 6.12 kernel needs DLA-4724-1.
Not affected: Ubuntu 22.04 GA on 5.15, Ubuntu 20.04/18.04, RHEL 8/7/6 and EL8 rebuilds, Debian 11.
Note: RHEL 9 reports a 5.14-based kernel numerically older than 6.7, but the feature (vsock MSG_ZEROCOPY) was backported.
Mitigation
1. Keep io_uring denied — on EL9/10 a value of 2 is already normal, so verify rather than change. On Ubuntu, disabling io_uring removes functionality apps may depend on (databases, proxies, high-throughput storage), so treat it as a real operational change; a value of 1 with kernel.io_uring_group can scope it to one group.
2. Remove the vsock transport where nothing needs it — blacklisting the module on bare metal with no vsock consumers is usually uneventful, but don't apply it blindly to a guest (QEMU guest agent, VMware Tools, nested virtualization all use vsock).
Check exposure with:
uname -r
sysctl kernel.io_uring_disabled
lsmod | grep -E 'vsock|vmw_vsock'
Current Status
The KernelCare team is working on rebootless live patches for most affected distros. Patches are expected to be deployed in the next 24/48hs. Once patches land:
kcarectl --update
kcarectl --patch-info | grep 'CVE-2026-53365'
Where that returns nothing, don't read the absence as coverage or as a gap — confirm the exact kernel with support before removing a temporary mitigation.
Posted Aug 20, 2026 - 06:30 UTC