CVE-2026-99999 Guest-to-Host Escape: mitigation and kernel update for CloudLinux

CVE-2026-99999 lets an untrusted guest on a virtualization host corrupt the host’s network stack with crafted checksum offload metadata. Kernel.org reported it. The CVE record describes the VM-guest case. The same code is reachable by other routes on some configurations, covered below.

The bug dates to Linux v2.6.27, so every CloudLinux kernel line is expected to carry it. We have not checked each tree.

Why it matters

If you run VPS hosting, the “guest” is your customer. Anyone who rents a VM can send the crafted metadata, and the host’s virtual machine monitor (VMM, such as QEMU) already forwards it. No host device access and no user namespace is needed. User namespace settings do not protect against this path.

On shared hosting without VMs, the question is whether a tenant can create an unprivileged user and network namespace. We consider that path plausible from the code, and we have not confirmed it.

Affected CloudLinux versions

Version	Affected	Status
CloudLinux 7 (CL7), kernel 3.10	⚠️ Conditional. Local path closed on our test system.	Kernel: ⏳ Pending Livepatch: ⏳ In preparation
CloudLinux 7h (CL7h), kernel 4.18	⚠️ Conditional. VM guests: yes. Local users: where unprivileged user namespaces are enabled.	Kernel: ⏳ Pending Livepatch: ⏳ In preparation
CloudLinux 8 (CL8), kernel 4.18	⚠️ Conditional. VM guests: yes. Local users: where unprivileged user namespaces are enabled.	Kernel: ⏳ Pending Livepatch: ⏳ In preparation
CloudLinux 8 LTS (CL8 LTS), kernel 5.14 (TuxCare ELS)	⚠️ Conditional. VM guests: yes. Local users: where unprivileged user namespaces are enabled.	Kernel: ⏳ Pending Livepatch: ⏳ In preparation
CloudLinux 9 (CL9), kernel 5.14	⚠️ Conditional. VM guests: yes. Local users: where unprivileged user namespaces are enabled.	Kernel: ⏳ Waiting for the AlmaLinux fix Livepatch: ⏳ Rolling out
CloudLinux 9 LTS (CL9 LTS), kernel 5.14 (TuxCare ELS)	⚠️ Conditional. VM guests: yes. Local users: where unprivileged user namespaces are enabled.	Kernel: ⏳ Pending Livepatch: ⏳ In preparation
CloudLinux 10 (CL10), kernel 6.12	⚠️ Conditional. VM guests: yes. Local users: where unprivileged user namespaces are enabled.	Kernel: ⏳ Pending Livepatch: ⏳ In preparation
CloudLinux for Ubuntu 22.04, kernel 5.15	⚠️ Conditional. VM guests: yes. Local users: where unprivileged user namespaces are enabled.	Kernel: ⏳ Pending Livepatch: ⏳ In preparation

† CloudLinux for Ubuntu 22.04 runs the stock Ubuntu kernel. The fix arrives from Canonical through apt, with no CloudLinux kernel stream.

KernelCare delivers the fix as a livepatch, without a reboot. It is rolling out for el9 now, and the el8 and el10 patches are in progress.

On servers licensed through CloudLinux Network (CLN) the livepatch applies automatically. Servers managed through KernelCare ePortal follow the rules set there.

Am I exposed?

Exposure depends on how a server is used, not on its kernel version.

• The host runs untrusted VM guests. It is exposed regardless of its user namespace settings, until it is patched or checksum offload is turned off for those guests.
• Shared hosting without VMs. The local path needs an unprivileged user who can create a user and network namespace. Run sysctl user.max_user_namespaces: a value of 0 means tenants cannot create one. To confirm, run unshare -Urn as an unprivileged user. If it fails, the local path is closed.

Unprivileged user namespaces are on by default on CloudLinux 8 and later, so do not assume a CloudLinux 10 server has them off. In our tests on CloudLinux 7h, 8, 8 LTS, 9 and 9 LTS, the local path produced no kernel oops and no Kernel Address Sanitizer (KASAN) report, so we have not confirmed that it is exploitable.

Is there a mitigation?

Partial workarounds exist. None has been tested against this bug yet, and each removes one prerequisite. The fixed kernel or the KernelCare livepatch is the remedy. In order of preference:

1. Update to the fixed kernel for your delivery stream when it ships. A reboot is required.
2. Apply the KernelCare livepatch once it is released for your kernel. No reboot is required.
3. On hosts that run untrusted VM guests, stop offering checksum offload to them.
4. Against the local path, disable unprivileged user namespaces.

Stop offering checksum offload to untrusted guests

• QEMU:

 -device virtio-net-pci,netdev=n0,csum=off,guest_csum=off

• libvirt:

 <driver><host csum='off'/><guest csum='off'/></driver> inside the <interface> element.

Compatibility: this is set per VM and needs a guest restart. It lowers guest network throughput because the guest loses TCP segmentation offload (TSO) and generic segmentation offload (GSO).

Disable unprivileged user namespaces (local path only, no effect on VM guests)

sysctl -w user.max_user_namespaces=0

echo "user.max_user_namespaces = 0" > /etc/sysctl.d/90-no-userns.conf

Compatibility: this breaks rootless containers and the Chrome and Flatpak sandboxes. To revert, delete the file and set the previous value back.

CageFS, CloudLinux’s virtualized filesystem that isolates each hosting account, does not close this.

Update instructions

Stream 1: CloudLinux kernel (CloudLinux 7h, 8)

Status: The fixed kernel is not yet available. CloudLinux rebuilds the kernel once the upstream fix lands. The target version will be added here on release.

Once the build reaches the testing channel:

# CloudLinux 8

yum update 'kernel*' --enablerepo=cloudlinux-updates-testing

reboot

# CloudLinux 7h

yum update 'kernel*' --enablerepo=cl7h_beta

reboot

After promotion to the stable channel, yum update kernel; reboot is enough.

Stream 2: AlmaLinux kernel (CloudLinux 9, 10)

Status: The fixed kernel is not yet available. CloudLinux 9 and 10 take the AlmaLinux kernel, so the fix arrives when AlmaLinux ships it. The target version will be added here on release.

Once the kernel reaches the AlmaLinux testing repository, install the testing release package from the AlmaLinux repo URL, update, reboot, then disable the testing repository:

# CloudLinux 10

dnf install -y https://repo.almalinux.org/almalinux/10/extras/x86_64/os/Packages/almalinux-release-testing-<ver>.el10.x86_64.rpm

dnf update 'kernel*'

reboot

dnf config-manager --disable almalinux-testing

CloudLinux 9 follows the same steps with the el9 package. Once the kernel reaches the production repositories, dnf update kernel; reboot is enough.

Stream 3: TuxCare ELS kernel (CloudLinux 8 LTS, 9 LTS)

Status: The fixed kernel is not yet available. CloudLinux 8 LTS and 9 LTS receive kernels through TuxCare Endless Lifecycle Support (ELS), which backports fixes independently.

ELS-subscribed servers install kernel-lts from the ELS repository.

Stream 4: KernelCare livepatch (all affected versions)

Status: KernelCare livepatch is currently available in the test feed for the EL9 family and will be released to the main feed later today.

• K20261016_0001: RHEL 9 — in testing
• K20261016_0002: AlmaLinux 9 and CloudLinux 9 — currently in the main feed
• K20261016_0004: Oracle Linux 9 — in testing
• K20261016_0005 / K20261016_0006: Rocky Linux 9 — in testing

Patches for el8 and el10 are in progress.

When a livepatch is published, pull it from the testing feed first, then from the main feed:

kcarectl –update –prefix test

kcarectl –update

How to verify you are patched

Kernel streams:

compare uname -r with the target version in the most recent update callout for your stream.

KernelCare:

run kcarectl --patch-info | grep CVE-2026-99999. [NEEDS: add every companion CVE the fix requires] Use --patch-info: kcarectl --info | grep CVE-2026-99999

It returns nothing even on a patched server.

---

Why this matters on a hosting platform

On a VPS or virtual machine host, the attack starts with a customer. A guest sends crafted virtio-net checksum metadata, the host forwards it into its IPv4 stack, and the flaw lets the guest leak host heap memory and crash the host. The researcher also reports code execution as root on a test host. That chain is not public, and we have not verified it.

If it holds, root on the host puts every other guest on that machine within reach, and patching removes that step from an attacker’s plan.

On shared hosting, the local path matters only where tenants can create user namespaces. The attacker there is whoever compromised one of the sites you host, not a customer you trust. They would create an unprivileged user and network namespace, which grants the capability to create a TAP device (a virtual network interface) with the virtio-net header enabled, and then feed the crafted value into the stack. This is plausible from the code. We have not confirmed it.

Technical details of CVE-2026-99999

virtio-net is the paravirtualized network device that virtual machines use. With checksum offload, the guest hands the host a packet whose checksum is unfinished, along with a header field, csum_start, that says where the checksum begins.

The attacker sets csum_start to point inside the IPv4 header. The packet reaches the host’s IPv4 stack, where ip_do_fragment() calls skb_checksum_help(). That function writes two attacker-controlled bytes into the IPv4 header, which the kernel had already validated. The write stays inside the packet buffer.

The kernel then re-reads the header length (ihl) and copies that many bytes of header into every fragment. Up to 40 bytes of nearby host heap memory leak back to the sender per fragment.

Four routes feed the same offload metadata:

• An untrusted VM guest through TAP or vhost-net (the in-kernel virtio-net backend). This is the case in the CVE record, and the VMM forwards the guest’s offload header.
• An unprivileged local user through tun with IFF_VNET_HDR, inside a user namespace. Plausible from the code, not confirmed in our tests.
• An AF_PACKET socket with PACKET_VNET_HDR. It needs CAP_NET_RAW, which is also available inside a user namespace.
• The owner of a macvtap or ipvtap device.

No public proof-of-concept exists, so we have not reproduced the attack. The host memory leak, the crash, and the root code execution come from the researcher’s test host.