IPv6 Frag Escape: CloudLinux 10 mitigation and kernel update (CL7 / 7h / 8 / 9 not affected)

A public, working proof-of-concept named IPv6 Frag Escape (ipv6_frag_escape) turns an unprivileged local user — including one confined inside an unprivileged container — into root on the host. It exploits a bug in the Linux kernel’s IPv6 output path present in the 6.12 kernel line. No CVE has been assigned yet. On CloudLinux, only CloudLinux 10 is affected. CL7, CL7h, CL8, and CL9 are not affected.

What it is

The bug is an arithmetic error in __ip6_append_data() (net/ipv6/ip6_output.c), the function that assembles outgoing IPv6 packets. On the paged-allocation path the kernel undersizes the packet’s head buffer by the number of bytes it then copies into it, so the copy runs past the end of the allocation and corrupts the adjacent skb_shared_info structure. An unprivileged process reaches this over UDPv6 sockets using MSG_MORE together with MSG_SPLICE_PAGES.

From that overflow the public exploit builds a full chain: it corrupts a page-reference count into a use-after-free on a page the attacker still controls, reclaims that page as a kernel page table (a “Dirty-Pagetable” primitive), and from there gains arbitrary kernel read/write. That is enough to overwrite the calling process’s credentials to root, neutralize SELinux in memory, and hijack core_pattern to run a program as root in the host’s initial namespaces, which is how a process inside an unprivileged container ends up with an interactive root shell on the host.

The public PoC does exactly that on stock EL10 kernels. We reproduced it in-house on AlmaLinux 10.2 (6.12.0-211.7.3.el10_2): an unprivileged user obtained a genuine host root shell. Because CloudLinux 10 uses the same AlmaLinux 10 kernel and build configuration, it is affected on the same terms.

The bug was fixed upstream in Linux 7.2-rc1 (commit 736b380e28d0). There is no stable-kernel backport yet outside the distro rebuilds described below, and no CVE has been assigned.

Details: public PoC · upstream fix (7.2-rc1) · AlmaLinux advisory · NVD entry not yet assigned

Affected CloudLinux versions

¹ The trigger for this bug reaches the kernel only via MSG_SPLICE_PAGES on UDPv6, which was added to the send path in Linux 6.6. CL7 (kernel 3.10), CL7h and CL8 (4.18), and CL9 (5.14) do not carry that code path, so the exploit’s send-side entry point returns -EINVAL on any of them and the vulnerable arithmetic is never reached. Only CloudLinux 10 (6.12) ships an in-window kernel.

A KernelCare livepatch that deploys the fix on CloudLinux 10 without a reboot is available as an alternative to the kernel update. See the KernelCare path below for current status.

Apply this mitigation now on CloudLinux 10

The fastest way to close this on CloudLinux 10 without a reboot is the KernelCare livepatch (see below). If you can take a reboot, the AlmaLinux patched kernel is the durable fix. Until you have applied one of those, the following interim mitigations reduce exposure. They are stopgaps, not a substitute for the patched kernel or livepatch.

Option A — Enable init_on_alloc (the decisive mitigation; requires a reboot)

EL10 kernels ship with allocator zero-on-allocation off, which is what makes the exploit’s page-reuse step reliable. Turning it on degrades the public technique to a crash rather than a root shell:

grubby --update-kernel=ALL --args="init_on_alloc=1"
reboot

init_on_alloc is usually a compile-time default, so it does not show on /proc/cmdline — check the kernel config and the runtime view instead:

grep CONFIG_INIT_ON_ALLOC_DEFAULT_ON /boot/config-$(uname -r)   # =y means on
cat /sys/module/page_alloc/parameters/init_on_alloc 2>/dev/null # 1 = on at runtime

Compatibility: init_on_alloc=1 carries a small allocator performance cost and requires a reboot to take effect. If you are rebooting anyway, prefer installing the patched kernel directly.

Option B — Disable unprivileged user namespaces (no reboot; removes the container-escape primitive)

This blocks the container-to-host escape path that the public PoC relies on:

sudo sysctl -w user.max_user_namespaces=0

To make it persist across reboots, add user.max_user_namespaces = 0 to a file in /etc/sysctl.d/ and run sysctl –system:

echo 'user.max_user_namespaces = 0' | sudo tee /etc/sysctl.d/99-ipv6-frag-escape.conf
sudo sysctl --system

Compatibility: this breaks rootless Podman/Docker and unprivileged-user-namespace browser sandboxes. Apply it only on hosts where unprivileged user namespaces are not needed. It removes the container-escape primitive but is not a complete fix for the underlying kernel bug. Treat it as defense in depth while you deploy the livepatch or patched kernel.

Update instructions for CloudLinux 10

As patches land, this article will be updated in place. Check the timestamps on the callouts below.

AlmaLinux kernel update (reboot required)

CloudLinux 10 uses the AlmaLinux 10 kernel directly. The patched kernel appears first in the AlmaLinux testing repository, with promotion to production shortly after.

Installing from the AlmaLinux testing repository

Enable the AlmaLinux 10 testing repository, update the kernel, reboot, then disable testing again. These match the steps AlmaLinux publishes for this vulnerability:

# 1. Enable the AlmaLinux 10 testing repo
sudo dnf install -y almalinux-release-testing

# 2. Update the kernel from the testing repo
sudo dnf update 'kernel*' --enablerepo=almalinux-testing

# 3. Reboot
sudo reboot

# 4. Verify the running kernel
uname -r
rpm -q kernel

# 5. Disable the testing repo
sudo dnf config-manager --disable almalinux-testing

If almalinux-release-testing is not available in your configured CloudLinux 10 repositories, install it directly from AlmaLinux in place of step 1:

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

Once the kernel reaches AlmaLinux production repositories

A plain update will pull the patched version, no testing-repo step needed:

dnf update 'kernel*'
reboot
uname -r

KernelCare livepatch (no reboot)

The KernelCare livepatch is shipped to the testing feed first and promoted to the main feed after validation. To deploy from the testing feed now:

kcarectl --update --prefix test

Once promoted to the main feed, KernelCare-subscribed servers receive the fix automatically through the standard livepatch flow:

kcarectl --update

Not using KernelCare yet? You can roll the fix out across your entire CL10 fleet automatically, without reboots. Get started in a few minutes — more information here.

How to verify you are patched

After a kernel update and reboot:

uname -r

Compare against 6.12.0-211.28.2.el10_2 (or the current target in the AlmaLinux-kernel callout above).

For KernelCare — because no CVE is assigned yet, verify by build time:

kcarectl --info | grep kpatch-build-time

Expected output on a patched system:

kpatch-build-time: Tue Jun 30 09:12:34 UTC 2026

Any build time on or after 2026-06-30 includes the IPv6 Frag Escape fix. If the output shows an earlier date, or is empty, the livepatch is not applied yet — run kcarectl –update –prefix test (or kcarectl –update once promoted to main) and re-check. Once a CVE is assigned and the patch metadata is finalized, kcarectl –patch-info | grep CVE-… will also confirm the fix is present.

References

• Public PoC repository (sgkdev/ipv6_frag_escape)
• Upstream fix (Linux 7.2-rc1, merge 38becddc)
• AlmaLinux advisory — IPv6 Frag Escape
• NVD entry — no CVE assigned yet