📋 TL;DR — as of 19 August 2026

VsockDrop (CVE-2026-53365) is a Linux kernel flaw that lets an unprivileged local user become root. It combines the kernel’s io_uring interface with the local vsock (VM sockets) transport, and needs no virtual machine, no container, and no special privileges.

  • Am I affected? No CloudLinux version is exposed in the configuration it ships with. The vulnerable code is absent entirely on CloudLinux 7, 7h, 8, 8 LTS, and 9 LTS, and on CloudLinux for Ubuntu 22.04’s default 5.15 kernel. On CloudLinux 9 and 10 the code is present, but the entry point it needs is switched off for every user, including root.
  • When you could be exposed: only if an administrator has deliberately re-enabled io_uring on CloudLinux 9 or 10, or has moved a CloudLinux for Ubuntu 22.04 server onto the newer 6.8 HWE kernel.
  • What to do: run the two-command self-check below. On a stock server there is no emergency, no reboot, and no action required.

VsockDrop (CVE-2026-53365) is a local privilege-escalation flaw in the Linux kernel, published in August 2026 by the security researcher Maher Azzouzi, who also originally reported it. On a vulnerable system, any unprivileged local user can gain a full root shell from a single static binary. It needs no virtual machine, no hypervisor, no container, and no user namespaces. A shared-hosting server is exactly the environment where untrusted users already have a local shell, so we checked every CloudLinux version against it: none is exposed in the configuration it ships with.

Am I affected?

You can settle your exposure in one command.

On the EL-based versions (CloudLinux 7, 7h, 8, 8 LTS, 9, 9 LTS, and 10), check whether the io_uring entry point is open:

sysctl kernel.io_uring_disabled

Expect 2 on CloudLinux 9 and 10, and No such file or directory on the older lines and the LTS kernels. Anything other than 2 on CloudLinux 9 or 10 means the entry point has been opened, and the server should be reviewed.

On CloudLinux for Ubuntu 22.04, check the kernel line:

uname -r

Expect a 5.15 kernel, which is not affected. A 6.8 kernel means the server has been moved onto the HWE line, which Canonical currently lists as affected with no fix released.

 

Affected CloudLinux versions

Exposure here is driven by configuration, not by version number, so the self-check above is the reliable test. The table shows the answer for each version as it ships.

Version Affected Notes
CloudLinux 7
Kernel 3.10		 ✅
Not affected		 io_uring and the zero-copy send feature are absent from this kernel.
CloudLinux 7h
Kernel 4.18		 ✅
Not affected		 No io_uring interface exists in this kernel; the local transport rejects zero-copy sends.
CloudLinux 8
Kernel 4.18		 ✅
Not affected		 No io_uring interface exists in this kernel; the local transport rejects zero-copy sends.
CloudLinux 8 LTS
Kernel 5.14		 ✅
Not affected		 io_uring is compiled out of this kernel, and the zero-copy send feature is absent. This is a build-time property and cannot be re-enabled.
CloudLinux 9
Kernel 5.14		 ⚠️
Not by default		 The vulnerable code is present, but io_uring is denied to every user, including root. Exposed only if an administrator re-enables io_uring.
CloudLinux 9 LTS
Kernel 5.14		 ✅
Not affected		 io_uring is compiled out of this kernel, and the zero-copy send feature is absent. Cannot be re-enabled.
CloudLinux 10
Kernel 6.12		 ⚠️
Not by default		 The vulnerable code is present, but io_uring is denied to every user, including root. Exposed only if an administrator re-enables io_uring.
CloudLinux for Ubuntu 22.04
Kernel 5.15 GA		 ✅
Not affected		 The 5.15 kernel does not support the zero-copy send the exploit needs. But: the 6.8 HWE kernel is listed as affected with no fix released.

 

Is there a mitigation?

The exploit needs two independent ingredients, and removing either one breaks it. On a stock CloudLinux 9 or 10 server the first is already in place, so the steps below are defense in depth for the two conditional cases: a server where io_uring has been re-enabled, or a CloudLinux for Ubuntu host running the 6.8 HWE kernel.

1. Keep io_uring denied.

sysctl kernel.io_uring_disabled          # expect: 2
printf 'kernel.io_uring_disabled = 2\n' > /etc/sysctl.d/99-io_uring.conf
sysctl --system

On CloudLinux 9 and 10 this only confirms a setting that is already active. On CloudLinux for Ubuntu 22.04 it is a real change: it turns io_uring off on a system where it is currently on, and anything that relies on io_uring will stop working. Where a specific service genuinely needs it, setting the value to 1 together with kernel.io_uring_group restricts it to a named group instead of denying it to everyone. Revert by removing the drop-in file.

2. Block the vsock transports. This removes the second ingredient. On a bare-metal shared-hosting server these modules are normally unused.

lsmod | grep -E 'vsock|vmw_vsock'        # check nothing is using them first

cat > /etc/modprobe.d/99-vsock.conf <<'EOF'
install vsock_loopback /bin/false
install vmw_vsock_virtio_transport /bin/false
install vsock /bin/false
EOF

An unprivileged user opening a vsock socket is enough to make the kernel load these modules on its own, so install … /bin/false is used rather than blacklist, which does not prevent that. Modules already loaded need to be removed with rmmod, or the server rebooted, before the change takes effect. Do not apply this on a server that is itself a virtual guest: the guest agents for QEMU and VMware use these transports. Revert by deleting the drop-in.

For operators running an exposed system, KernelCare will deliver the fix as a live patch once one is published, applied to the running kernel with no reboot. Until then, the mitigations above are the available protection.

The rest of this advisory is background for operators who want it: why the CloudLinux default shuts this down, and how the underlying bug works. None of it is required to act on the check above.

Why stock CloudLinux is not exposed

The exploit chain has two halves, and it needs both. The first is the kernel’s io_uring interface, specifically its zero-copy send operation with pre-registered buffers. The second is the local vsock transport accepting zero-copy sends. Remove either half and the chain is dead. That is the researcher’s own conclusion, and it is why the CloudLinux line-up is not reachable.

Every CloudLinux version removes at least one of the two, and on most of them the ingredient is missing at compile time rather than switched off by a setting:

  • On CloudLinux 7, 7h, and 8, the kernel provides no io_uring interface at all, and the local transport rejects zero-copy sends. Both halves are absent.
  • On CloudLinux 8 LTS and 9 LTS, io_uring is not compiled into the kernel, and the zero-copy send feature is absent from the local transport. Because this is a build-time property, it cannot be turned back on with a setting.
  • On CloudLinux 9 and 10, the vulnerable code is present, but io_uring is switched off by default. The setting kernel.io_uring_disabled ships at 2, its most restrictive value, which blocks io_uring for every user. At this setting even a root process cannot open an io_uring instance, so the first half of the chain is closed before it can start. An administrator can still lower the setting to re-enable io_uring for a workload that needs it, and only that deliberate change brings the vulnerable code within reach.
  • On CloudLinux for Ubuntu 22.04, io_uring is available, because the platform inherits Ubuntu’s default. But the running 5.15 kernel does not support the specific zero-copy send operation the exploit needs, so the second half of the chain is missing.

The one change that moves a CloudLinux server into exposure is on CloudLinux for Ubuntu 22.04: the 6.8 HWE kernel is a single package install away, it is offered by the standard repository, and many administrators move to it for newer hardware support. Canonical lists that kernel line as affected with no fix released.

 

How the bug works

The defect is in the kernel’s zero-copy send path over vsock. When a program sends data with zero-copy, the kernel borrows the program’s memory pages directly instead of making a copy, and it keeps a reference on each page until the send completes, so the page is not freed while still in use. On a large, fragmented send, the kernel attaches its completion-tracking record to only the last fragment. The earlier fragments still hold borrowed pages but carry no record, so when they are released the kernel runs its cleanup as if it were balancing a reference it never took, and drops one it does not own.

Repeat that enough times and the reference count on a page the kernel is still holding reaches zero, and the page is handed back to the free pool while the attacker’s program still has it mapped through an io_uring pre-registered buffer. The attacker then reads a setuid-root program, such as su, which causes the kernel to pull that just-freed page back in as the program’s cached copy. Because the attacker still owns the same memory, they rewrite the program’s interpreter path to point at code of their own and run it. The kernel starts it with root privileges.

The reason io_uring is load-bearing is that its registered-buffer send is the path that hands the kernel long-term pinned pages without taking an ordinary reference on them. An ordinary send takes proper references and stays balanced, so the underflow never happens. That is why denying io_uring, or removing the vsock transport, is enough to break the whole chain.

 

References