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 packet-output path present in the 6.12 kernel line. On CloudLinux, only CloudLinux 10 is affected. CL7, CL7h, CL8, CL9 and CloudLinux for Ubuntu 22.04 are not.

We first published this advisory on July 1, 2026, when the vulnerability had no CVE assigned. Since then MITRE has assigned two IDs, an IPv4 companion has been identified, and both CloudLinux 10 fix paths have reached general availability. The IPv4 companion was already covered by the fix we shipped on June 30, so there is nothing extra to apply.

On an affected CloudLinux 10 server, this is the difference between one hacked website and a compromised server. “Local” here does not mean an insider or a customer you trust. It means any process on the machine, including the PHP-FPM worker behind a compromised WordPress plugin or an outdated CMS. The attacker is whoever hacked one of the sites you host.

Affected CloudLinux versions

Both CVEs affect the Linux kernel from 6.0 onward. CloudLinux 10 is the only CloudLinux platform that ships an in-range kernel.

¹ NVD lists both CVEs as affecting kernels from 6.0 up to the fixed stable builds. Every CloudLinux kernel other than CloudLinux 10’s sits below that floor: CL7 (3.10), CL7h and CL8 (4.18), CL9 (5.14), CloudLinux for Ubuntu 22.04 (5.15). None of them carry the MSG_SPLICE_PAGES UDP send path the public exploit uses. On those kernels the exploit’s send-side entry point returns -EINVAL, so the vulnerable arithmetic is never reached. CloudLinux 8 LTS and CloudLinux 9 LTS run the same 4.18 and 5.14 kernel lines and are likewise below the affected range.

² CloudLinux for Ubuntu 22.04 takes its kernel from Ubuntu (Canonical), not from a CloudLinux stream. The 5.15 GA kernel it ships is outside the affected range.

A KernelCare livepatch is available as a no-reboot alternative on CloudLinux 10.

Is there a mitigation?

Both fix paths are now generally available, so the mitigations below are no longer the recommended route. Use them only on a CloudLinux 10 host you cannot patch or livepatch immediately. They reduce exposure, but they do not replace the fix.

1. 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, install the patched kernel instead.

2. 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:

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 leaves the underlying kernel bug reachable by a local process outside a container. Treat it as defense in depth while you deploy the livepatch or patched kernel.

Update instructions

Two delivery streams cover CloudLinux 10. Either one closes both CVEs.

Stream 1: AlmaLinux kernel (CL10)

CloudLinux 10 uses the AlmaLinux 10 kernel directly. Update the kernel and reboot:

dnf update 'kernel*'
reboot
uname -r

If you enabled the AlmaLinux testing repository earlier in this incident to get the kernel ahead of promotion, disable it again now that the build is in stable:

dnf config-manager --disable almalinux-testing

Stream 2: KernelCare livepatch (CL10)

KernelCare-subscribed servers receive the livepatch automatically on the next update cycle, or on demand:

kcarectl --update

Not using KernelCare yet? You can roll the fix out across your entire CloudLinux 10 fleet automatically, with no reboots. More information here.

How to verify you are patched

Stream 1 (kernel update).

After updating and rebooting:

uname -r

Any build at 6.12.0-211.28.2.el10_2 or newer carries both fixes.

Stream 2 (KernelCare).

Check for either CVE ID:

kcarectl --patch-info | grep -E 'CVE-2026-53362|CVE-2026-53366'

The livepatch was built on June 30, before either ID was assigned, so its metadata may not cite them. If the grep returns nothing, confirm by build time instead:

kcarectl --info | grep kpatch-build-time

Any build time on or after 2026-06-30 includes the fix.

Why this bug matters on a shared host

On an unpatched CloudLinux 10 host the chain is short, and none of it needs special access:

1. A web-tier compromise. An attacker exploits a vulnerable plugin or an outdated CMS, and now runs as an unprivileged process confined to a single site.
2. Frag Escape or Frag Gap. From that restricted process, the attacker uses the kernel bug to become root. No prior root, no special capability, no admin action.
3. Root on the host. They now run outside every tenant boundary and per-account limit. Every other tenant’s files, databases, credentials, and backups on that server are within reach, and in the worst case recovery means rebuilding the server.

On a patched host, or one running the KernelCare livepatch, step 2 fails: a web-tier compromise stays a web-tier compromise, one site to clean up rather than a whole server to rebuild. That is what the kernel update buys you.

Technical details of the bug

The bug is an accounting error in the kernel’s packet-append path. In __ip6_append_data() (net/ipv6/ip6_output.c), when the paged-allocation branch is taken, the kernel computes the allocation size without accounting for fraggap, the bytes carried over from the previous socket buffer. Those bytes are then copied into the new buffer’s linear area anyway. The linear area ends up undersized by fraggap bytes while the paged length is overstated by the same amount, so the copy runs past skb->end and corrupts the trailing skb_shared_info structure. An unprivileged process reaches this over a UDPv6 socket using MSG_MORE together with MSG_SPLICE_PAGES.

Two upstream commits explain why only recent kernels are exposed. The bad accounting arrived with 773ba4fe9104 (“ipv6: avoid partial copy for zc”). Before ce650a166335 (“udp6: Fix __ip6_append_data()‘s handling of MSG_SPLICE_PAGES”), the resulting negative copy length caused the kernel to return -EINVAL; that later commit allowed the MSG_SPLICE_PAGES case to proceed, which is what made the corruption triggerable.

The IPv4 companion. CVE-2026-53366 (Frag Gap) is the same arithmetic error in __ip_append_data() (net/ipv4/ip_output.c), where the carried-over fraggap bytes are copied into the new buffer’s linear area by skb_copy_and_csum_bits(). NVD’s entry documents the accounting error itself and does not describe a trigger sequence, and the public exploit chain targets the IPv6 path. Both are closed by the same correction: add fraggap to the allocation length and subtract it from the paged length.

From the 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.

Both CVEs carry a CVSS 3.1 base score of 7.8 (High).

References

• NVD entry: CVE-2026-53362 (Frag Escape, IPv6)
• NVD entry: CVE-2026-53366 (Frag Gap, IPv4)
• Public PoC repository: sgkdev/ipv6_frag_escape
• Upstream fix (IPv6): commit 736b380e28d0
• AlmaLinux advisory: IPv6 Frag Escape