How VsockDrop Reaches Root With No Hypervisor and No Privileges

The Short Version

Jump to the Long Version ↓

A Linux kernel flaw scored at 5.5 now has a public exploit that turns an unprivileged local user into root. That is the part of VsockDrop (CVE-2026-53365) worth acting on this week.

What it is: VsockDrop is a local privilege escalation (LPE) exploit for CVE-2026-53365, a defect in the Linux kernel’s virtio vsock zerocopy send path. When a large MSG_ZEROCOPY sends fragments across several socket buffers, only the last buffer carries the completion object that the release path looks for. Every buffer before it holds pinned user pages, and the kernel then drops a page reference it never took.

Potential impact: Root from an ordinary unprivileged account. The exploit drains a page reference count to zero, gets that still-pinned page handed back as page cache for /usr/bin/su, rewrites the interpreter path stored inside it, and runs su. There is no infoleak and no kernel code execution anywhere in the chain, which is a large part of why it works as consistently as it does.

Severity: Red Hat and NVD both publish a CVSS base score of 5.5 for CVE-2026-53365, with high availability impact and no confidentiality or integrity impact, and Red Hat rates it Moderate. The exploit’s author argues for a 7.8.The vector describes the resource-accounting failure the upstream commit message documents. It does not account for the io_uring interaction that turns the same missing completion object into a page freed while it is still in use. Whatever the eventual scoring outcome, the public exploit demonstrates confidentiality and integrity consequences that the currently published 5.5 vector does not capture.

Who is exposed: Ubuntu deserves the most immediate attention. Linux kernels from 6.7 onward that have not taken the fix are affected, and reachability depends on an unprivileged process being able to use io_uring registered buffers together with a vsock transport that permits zerocopy. Both are available by default on Ubuntu 24.04 and on Ubuntu 22.04 running the 6.8 HWE kernel. Enterprise Linux 9 and 10, including RHEL, AlmaLinux, Rocky and CloudLinux, carry the same vulnerable code but ship with kernel.io_uring_disabled set to 2, which blocks the demonstrated chain.

What has been verified: On August 18, 2026, TuxCare reproduced a root shell on Ubuntu 24.04 from an unprivileged account on the first run, with no configuration changes. On AlmaLinux 10.2 the same exploit stopped at io_uring initialization as shipped, then produced root once io_uring was explicitly re-enabled. An AlmaLinux 9.8 attempt with io_uring re-enabled did not reach root, which is not the same as a clean negative.

What to do now: Identify the running kernel and the io_uring policy, then check whether vsock is loaded.

uname -r
sysctl kernel.io_uring_disabled
lsmod | grep -E 'vsock|vmw_vsock'

A value of 2 means io_uring setup is denied system-wide, root included, which blocks the known root exploit path without removing the vulnerable code. A value of 0 means io_uring is available, which is the upstream default and what Ubuntu ships. Output from the third command confirms that a vsock-related module is loaded. The public exploit can use vsock_loopback and VMADDR_CID_LOCAL, so a virtual machine is not required.

Apply a fixed vendor kernel where one exists. Debian 13 has one. Canonical has not shipped one for the two Ubuntu lines that matter most. Where a reboot cannot happen immediately, KernelCare is the usual route to a running kernel that no longer carries the bug, and no rebootless patch has been released for this CVE yet, so the mitigations below are what these systems have in the meantime.

The interesting part of VsockDrop is not that another Linux kernel CVE exists. It is the distance between what the CVE record describes and what the public exploit actually does.

CVE-2026-53365 was published on July 13, 2026, two months after the upstream fix had already landed on May 14. The official description covers zerocopy completion tracking and pinned pages that are never released, and both Red Hat and NVD score that at 5.5 with availability-only impact.

Then the public exploit changed the practical picture. It showed that the same reference-accounting flaw, combined with io_uring registered buffers, frees a page that is still pinned, reclaims it as part of a setuid binary, and turns an ordinary local user into root.

One defect, two consequences. The CVE captured the mild one. If a 5.5 in a vulnerability report is the reason this dropped off a patch list, it belongs back on.

What Is CVE-2026-53365, Also Known as VsockDrop, All About?

VsockDrop is an unprivileged local privilege escalation exploit for CVE-2026-53365 in the Linux kernel, published in August 2026 by Maher Azzouzi, who is credited as the reporter on the upstream fix. The name refers to the exploit and write-up rather than to a separate vulnerability.

The vulnerable code sits in the virtio vsock zerocopy send path. AF_VSOCK is usually associated with communication between a guest and its hypervisor, so the natural assumption is that this is a virtualization problem. It is not. Linux exposes a local vsock context ID through the vsock_loopback transport, VMADDR_CID_LOCAL, which is CID 1, and the proof of concept uses that endpoint to talk back to the same system. No hypervisor, no guest, no user namespace and no capability check sits between an ordinary account and the vulnerable code.

So the prerequisite is not control of a hypervisor. It is the ability to run a binary as a normal local user on an affected kernel where the required features are available. On shared hosting, multi-tenant build systems, CI runners and jump hosts, that describes most of the accounts on the box.

The second load-bearing piece is io_uring. The exploit uses registered buffers together with zerocopy sending, and that specific interaction is what turns a page-accounting bug into a reference underflow and then into root.

The timing matters too. The fix has been public since May 14, 2026, authored by Stefano Garzarella of Red Hat, and the exploit arrived roughly three months later. Nobody was ambushed here, which also means every unpatched kernel has been sitting in front of a published fix for a full quarter.

How the VsockDrop Root Exploit Works

A MSG_ZEROCOPY send does not copy the payload. The kernel pins the user pages, transmits from them, and later notifies userspace through the error queue when those pages are safe to reuse. The object that tracks all of that is the ubuf_info, usually called the uarg.

Under zerocopy, the vsock send path caps each socket buffer at 64 KiB, so anything larger fragments. Before the fix, the uarg was attached only to the final buffer in the loop. Earlier buffers still carried pinned pages, with none of the completion state the kernel expected to find there.

On its own, that produces the resource-accounting problem the CVE describes. Userspace is never told those pages are free, and if the send loop breaks early the uarg is never allocated at all.

With io_uring registered buffers, the consequences are different. Those pages are already long-term pinned, and the networking stack marks the fragments as managed references, meaning the release path should leave them alone. The guard that enforces that sits inside a check for whether the buffer has a uarg attached. No uarg means the check fails, the guard is never consulted, and the unref loop calls put_page() on fragments that never took a reference. The result is a stray page reference decrement on every send.

Sending the same payload through an ordinary iovec produces none of it. In that case io_uring takes proper references, the accounting balances, and only the memory leak remains. No io_uring, no underflow.

From there the arithmetic is unkind. The pin bias is 1024, a fixed ABI constant, so a known number of sends drains a known amount of reference count on any affected kernel. Register a buffer, unmap it, send until the count reaches zero, and the kernel frees a page that io_uring still holds a pin on. Read a cold page of /usr/bin/su and the allocator hands that same physical page straight back as page cache, because the freelist is last in, first out. The still-registered buffer now aliases that page cache, a fixed write rewrites the ELF interpreter path, and executing su makes the kernel load an attacker-supplied interpreter with root credentials already applied.

There is no kernel code execution in that chain. It is a data-only path to root, and if the shape looks familiar, it should. Copy Fail (CVE-2026-31431) used a related idea earlier in 2026, corrupting the page cache of a setuid binary to reach root without modifying the underlying file. VsockDrop arrives at a similar target through a very different kernel bug.

One detail matters for anyone testing this. The reference drain is deterministic. The page-reclaim stage is probabilistic, and a missed attempt cannot be retried on the same boot. So the exploit is dependable without being one-shot, and a single failed run is not evidence that a kernel is unaffected.

Has VsockDrop Been Confirmed Exploitable?

Yes, on an affected Ubuntu 24.04 kernel with no configuration changes.

TuxCare reproduced the public exploit on Ubuntu 24.04 on August 18, 2026, running a 6.17 Azure kernel. The run started from an unprivileged account and produced a root shell on the first attempt with nothing tuned or reconfigured. The only collateral was a BUG: Bad page state entry in dmesg. That image does not carry the fix, and Canonical has not released one for it.

AlmaLinux 10.2 behaved very differently. The exploit died immediately with io_uring init failed, which is the shipped kernel.io_uring_disabled = 2 default doing exactly its job. SELinux is not what stops it, in case that is the assumption sitting in the room. There were no AVC denials, and the run still failed with SELinux in permissive mode. With the sysctl set to 0, the next attempt returned root, with a clean dmesg and no oops.

Mitigated as shipped is not the same as fixed.

AlmaLinux 9.8 is the case worth being careful about. With io_uring re-enabled, the exploit ran end to end and then failed without producing root. That is not a clean negative. Every code precondition for the underflow is present in the shipped 5.14 kernel, the zerocopy send opcode the exploit needs has been backported into that kernel line, and Red Hat still marks RHEL 9 affected. The failure signature matched a known miss on a host that had already been rooted. Enterprise Linux 9 should be treated as affected in code until a proper test says otherwise.

A failed run also leaves evidence, which is more useful than it sounds. The exploit only cleans up after itself on success, so a miss leaves /tmp/loader and /var/tmp/.s behind, and /var/tmp/.s is setuid root. That is a local privilege escalation vector parked on the host by an attempt that did not even work, and nobody goes looking in /var/tmp. Remove it by hand.

A successful run breaks su until reboot, with cannot execute: required file not found. Dropping caches does not help, because the corrupted page still holds a reference, so only a reboot restores it. That is a cheap detection signal and a user-visible outage in its own right. The corruption stays in the page cache, and on AlmaLinux rpm -V util-linux-core came back clean afterward, so the binary on disk was untouched. On a copy-on-write filesystem that may not hold, per the exploit author’s own warning.

Is Ubuntu 24.04 Vulnerable to VsockDrop?

Yes. Affected Ubuntu 24.04 kernel lines are vulnerable, and the public root exploit has been reproduced on Ubuntu 24.04 with no configuration changes.

Canonical currently lists CVE-2026-53365 as vulnerable across the Noble kernel packages, covering the 6.8 GA line and the 6.17 HWE line, along with the AWS, Azure, GCP and GKE variants. Ubuntu 22.04 running the 6.8 HWE kernel is listed as vulnerable as well, and that is the larger install base of the two.

Ubuntu matters more than an affected-package list suggests, because its normal io_uring configuration leaves the exploit prerequisite available. Canonical also rates the CVE medium, which is why no security notice has been forced out for these lines.

The newer 7.0-based kernels are being worked on separately. Canonical currently lists both Ubuntu 26.04 and the Ubuntu 24.04 HWE 7.0 line as vulnerable with fixes in progress, so check the exact package status before assuming either one is corrected.

Which Linux Systems Are Affected?

Only the upstream picture is simple. The vsock MSG_ZEROCOPY work that introduced the behavior landed in Linux 6.7, and the stable fixes are in 6.12.97, 6.18.34, 7.0.11 and 7.1. Distribution kernels have to be assessed by advisory and package, because vendors backport features constantly. RHEL 9 reports a 5.14-based kernel, numerically older than 6.7, and Red Hat still marks RHEL 9 and RHEL 10 affected with no fix shipped, because the feature was backported into that kernel line.

Backports move both vulnerable features and fixes into version numbers that do not line up with upstream, so treat uname -r as an identifier to look up, not as the verdict.

What protects Enterprise Linux 9 and 10 is that default rather than a patch, and it is compiled into the kernel rather than shipped as a sysctl file, so anything booting that kernel inherits it unless userspace changes it afterward. Database, proxy and container workloads change it deliberately – which makes the exposure on those hosts real rather than hypothetical.

How to Mitigate VsockDrop

The demonstrated chain needs io_uring registered buffers and a vsock transport that permits zerocopy. Removing either prerequisite breaks it, which is a better position than most kernel bugs leave you in. Neither control is a substitute for the kernel fix.

1. Keep io_uring denied. On Enterprise Linux 9 and 10, a value of 2 is already the normal condition, so this is a verification step rather than a change. Avoid moving it unless a workload actually requires io_uring.

Ubuntu is the opposite case. Turning io_uring off there removes functionality that running applications may depend on, including databases, proxies and high-throughput storage software, so treat it as a real operational change with real blast radius. It is also the only runtime option those systems have until a fix arrives. Where one specific service needs io_uring, a value of 1 combined with kernel.io_uring_group allows it for members of that group only, and anything other than 2 should not be read as equivalent to fully disabled.

2. Remove the vsock transport where nothing needs it. On bare metal with no vsock consumers, blacklisting the module is usually uneventful.

lsmod | grep -E 'vsock|vmw_vsock'

Do not apply it blindly to a machine that is itself a guest. The QEMU guest agent and VMware Tools both use vsock transports, as does nested virtualization and anything Firecracker-style. Already-loaded modules need rmmod or a reboot before a blacklist means anything, so confirm the module is actually gone afterward.

Neither control has been tested against this specific exploit, so treat them as prerequisite removal rather than verified neutralization.

The VsockDrop Fix

The upstream correction is commit ae38d9179190, “vsock/virtio: fix zerocopy completion for multi-skb sends,” and it follows what TCP already does.

Instead of creating the uarg partway through the send loop and attaching it to whichever buffer happens to be last, the fix allocates it up front, attaches it to every buffer with a reference taken per buffer, and balances the initial reference afterward. Each completion decrements the count, the notification fires only once the last buffer is freed, and a send that fails without transmitting anything aborts the uarg cleanly.

That closes both consequences at once. Every buffer now carries a uarg, so the managed-fragment guard in the release path is consulted the way it was always meant to be, and the stray reference drops stop happening. Backport work varies with how far each vendor kernel has drifted from mainline.

The fix is in upstream stable 6.12.97, 6.18.34, 7.0.11 and 7.1. Vendor kernels can carry the same correction under entirely different version numbers.

Rebootless Patch Status for CVE-2026-53365

As of August 18, 2026, the KernelCare team is working on rebootless live patches for most of the affected distros. The first patches are expected to be deployed within 48 hours.

When patches land, they arrive on the next scheduled run, or on demand.

kcarectl --update

Then confirm what the running kernel is actually carrying.

kcarectl --patch-info | grep 'CVE-2026-53365'

Where that returns nothing, do not read the absence as coverage or as a gap. Confirm the exact kernel with support before removing a temporary mitigation, not after. A patch build timestamp is a weaker secondary signal and should not be treated as proof for any specific CVE.

Learn how KernelCare patches critical kernel vulnerabilities without rebooting → 

Common Questions About VsockDrop

What does an attacker need to exploit CVE-2026-53365? The ability to run a binary as an unprivileged local user on an affected kernel, with io_uring available and a vsock transport loadable. No hypervisor, no guest, no user namespace and no special hardware.

Does VsockDrop require a virtual machine? No, and that is the part most summaries get wrong. The vsock_loopback transport lets an unprivileged process talk to itself over the local CID, so a bare-metal host with no virtualization at all is still in range.

Are RHEL 9 and RHEL 10 affected by VsockDrop? Red Hat marks both as affected, including kernel-rt, with no fix shipped. The public exploit does not run as shipped, because those kernels deny io_uring by default, so the exposure shows up where that default has been changed.

Can CVE-2026-53365 be exploited remotely? No. It needs a local account. That still covers shared hosting, multi-tenant build systems, CI runners and any host where an application user can execute a binary.

How can you tell whether someone has tried it? Check for /var/tmp/.s, which a failed attempt leaves behind as a setuid root binary, and for /tmp/loader. A broken su reporting a missing required file, together with BUG: Bad page state in dmesg, points at a successful run on that boot.

Is there a patch for CVE-2026-53365? Upstream fixes are in 6.12.97, 6.18.34, 7.0.11 and 7.1, and Debian has shipped fixes for trixie and for the bookworm 6.12 kernel. Canonical has not shipped one for the affected Ubuntu lines, and no rebootless patch has been released for this CVE at the time of writing.

VsockDrop Timeline

References

• Maher Azzouzi, VsockDrop proof of concept and technical write-up, https://github.com/MaherAzzouzi/vsockdrop
• Linux upstream fix ae38d9179190, “vsock/virtio: fix zerocopy completion for multi-skb sends,” https://git.kernel.org/linus/ae38d9179190a956e2a87a69ef1dd6f451b51c4d
• Commit 581512a6dc93, “vsock/virtio: MSG_ZEROCOPY flag support,” which introduced the affected code in Linux 6.7
• Commit 1cb36e252211, the pinned-pages accounting fix whose review surfaced this defect
• Red Hat CVE-2026-53365, https://access.redhat.com/security/cve/cve-2026-53365
• NVD CVE-2026-53365, https://nvd.nist.gov/vuln/detail/CVE-2026-53365
• Ubuntu CVE-2026-53365, https://ubuntu.com/security/CVE-2026-53365
• Debian CVE-2026-53365, https://security-tracker.debian.org/tracker/CVE-2026-53365