Mitigating IPv6 Frag Escape (CVE-2026-53362) on Rocky Linux 10

cve cve-2026-53362 security kernel rocky linux mitigation troubleshooting container escape ipv6

Arsalan Zaidi
Customer Support Engineer

Jul 08, 2026

Introduction

IPv6 Frag Escape, tracked as CVE-2026-53362, is a local privilege escalation and container escape vulnerability in the Linux kernel's IPv6 fragmentation path. A missing bounds check in __ip6_append_data() causes an out-of-bounds write into skb_shared_info, which enables a page use-after-free. An attacker chains this into a dirty-pagetable attack that provides arbitrary kernel read/write, overwrites process credentials to gain uid=0, patches avc_denied() to bypass SELinux, and escapes from a container to root on the host via core_pattern.

This vulnerability is separate from the Dirty Frag (CVE-2026-43284) and Fragnesia (CVE-2026-46300) vulnerabilities. While all three involve kernel memory corruption, IPv6 Frag Escape uses the IPv6 fragmentation code path, not the ESP/xfrm subsystem.

This article covers Rocky Linux 10 systems on x86_64, including RLC Pro and RLC Pro Hardened variants, as well as CIQ Linux Kernel (CLK) 6.12 and 6.18 variants. Earlier Rocky Linux versions (8 and 9) running their default kernels (4.18.x and 5.14.x) are not affected because they do not contain the vulnerable code. CLK variants on Rocky 9 are affected because they run upstream 6.12.x and 6.18.x kernels that contain the vulnerable code path. The vulnerability does not affect aarch64 systems because it requires 5-level paging (LA57), which is an x86_64 feature.

Problem

IPv6 Frag Escape targets the kernel's IPv6 fragmentation reassembly path. When an attacker creates an IPv6 socket inside an unprivileged user namespace and sends crafted fragmented packets, the kernel's __ip6_append_data() function writes beyond the bounds of skb_shared_info. This corrupts adjacent memory and produces a page use-after-free condition. The attacker then uses a dirty-pagetable technique to convert the use-after-free into arbitrary kernel read/write access.

With arbitrary kernel access, the exploit overwrites the calling process's cred structure to set all UIDs and GIDs to 0 (root). It then patches the in-kernel avc_denied() function to neutralize SELinux enforcement. Finally, the exploit writes a malicious command to /proc/sys/kernel/core_pattern, which executes as root on the host when a process crashes, completing the escape from the container to the host.

The attack is local only. It cannot be exploited remotely. The attacker must have code execution inside a container or as a local unprivileged user on the host. The exploit requires access to unprivileged user namespaces, which are enabled by default on Rocky Linux 10.

Treat the following systems as affected unless they have the mitigation in place or are running a patched kernel:

RLC Pro variants based on Rocky Linux 10, including RLC Pro Hardened
CIQ Linux Kernel (CLK) 6.12 and 6.18 variants on Rocky Linux 9

The following systems are not affected:

Rocky Linux 8 and 9 default kernels (all variants, including LTS, FIPS, RLC Pro, and RLC Pro Hardened)
All aarch64 systems (the exploit requires x86_64 5-level paging)
CIQ Bridge / CentOS 7

Status

Patched kernels are available. See the Patched Kernels table below for current availability. CIQ updates this article as tested kernels become available for each variant.
Recommended action: install the patched kernel for your variant and reboot. If you cannot update immediately, apply the user namespace mitigation described in the Mitigation section below to block the exploit's entry point.
The mitigation has operational impact. Disabling unprivileged user namespaces breaks rootless Podman containers, application sandboxes (Chromium, Firefox, Flatpak), and anything that depends on unprivileged user namespace creation. Plan a maintenance window for systems running those workloads.
CIQ Bridge customers and CentOS 7.9 users are unaffected by this vulnerability.
Relationship to Dirty Frag and Fragnesia mitigations. If you already disabled unprivileged user namespaces (user.max_user_namespaces=0) as part of another advisory, that mitigation also covers IPv6 Frag Escape. The Dirty Frag module-blocking mitigation (esp4/esp6 in /etc/modprobe.d/dirtyfrag.conf) does not cover this vulnerability because IPv6 Frag Escape does not use the ESP code path.
Open a support case if you need help assessing exposure, validating workload impact, or tracking patched kernel availability for your specific CIQ variant.

Patched kernels

The Repo links require your CIQ depot credentials. If you need to retrieve them, log in to the CIQ Portal.

Variant	Patched Kernel Version	Repo	Released
RLC Pro 10	`kernel-6.12.0-211.32.1+2.1.el10_2_ciq`	ciq-scn-10.x86_64	2026-07-14
CIQ Linux Kernel (CLK) 6.12	`kernel-clk6.12-6.12.95-1.1.el9_clk`	clk-6.12-el9.x86_64	2026-07-06
CIQ Linux Kernel (CLK) 6.18	`kernel-clk6.18-6.18.38-2.1.el9_clk`	clk-6.18-el9.x86_64	2026-07-13

Confirm what is running on a given system with:

uname -r

If your system reports one of the patched versions above (or newer), the fix is in place and the mitigation can be reverted. See Reverting the mitigation.

ℹ️ NOTE CIQ updates this table as tested kernels become available for each variant.

Installing the Update

For RLC Pro 10 systems with CIQ depot configured:

sudo dnf update kernel*
sudo reboot

For CLK variants, update the CLK kernel package specifically:

sudo dnf update kernel-clk6.12*   # for CLK 6.12
sudo dnf update kernel-clk6.18*   # for CLK 6.18
sudo reboot

After rebooting, verify the running kernel matches a patched version from the table above with uname -r, then remove the mitigation sysctl if you applied it (see Reverting the mitigation).

Mitigation

Apply the steps in this section if you cannot install a patched kernel immediately. Once you install a patched kernel and reboot, the mitigation can be removed. See Reverting the mitigation.

Disable unprivileged user namespaces

The IPv6 Frag Escape exploit requires unprivileged user namespace creation to reach the vulnerable IPv6 fragmentation code path from inside a container. Setting user.max_user_namespaces to 0 removes that entry point and blocks the exploit.

⚠️ WARNING Disabling unprivileged user namespace creation breaks rootless container runtimes including rootless Podman, rootless Docker, slirp4netns, and pasta. It also breaks sandboxed browsers such as Chromium and Firefox, and Flatpak applications. Validate the impact on your workload before applying fleet-wide. Systems using rootless containers should plan a maintenance window.

To apply:

echo 'user.max_user_namespaces=0' | sudo tee /etc/sysctl.d/cve-2026-53362.conf
sudo sysctl --system

Verify:

sysctl user.max_user_namespaces

Output should be user.max_user_namespaces = 0.

This mitigation is broader than the Dirty Frag and Fragnesia mitigations that block esp4/esp6 modules or disable unprivileged network namespaces. Disabling user namespaces entirely also prevents the Dirty Frag and Fragnesia attack vectors, since those exploits also require user namespace access for their initial entry. If you apply this mitigation, it supersedes the narrower mitigations for those CVEs.

Reverting the mitigation

Once you install a patched kernel for your variant, remove the sysctl override to restore unprivileged user namespace creation:

sudo rm /etc/sysctl.d/cve-2026-53362.conf
sudo sysctl --system

Verify that user namespaces are re-enabled:

sysctl user.max_user_namespaces

The value should be greater than 0.

Verification

Verifying the mitigation

Confirm that unprivileged user namespaces are disabled:

sysctl user.max_user_namespaces

Output should be user.max_user_namespaces = 0.

Confirm the sysctl drop-in file is present and has the correct content:

cat /etc/sysctl.d/cve-2026-53362.conf

You should see user.max_user_namespaces=0.

As a functional test, confirm that an unprivileged user cannot create a user namespace:

unshare --user --map-root-user echo "user namespaces are enabled"

This command should fail with a permissions error when the mitigation is active. If it succeeds and prints the message, the sysctl is not in effect. Re-run sudo sysctl --system and check for conflicting sysctl files that may override the setting.

Verifying the patched kernel

Confirm the running kernel matches a patched version:

uname -r

Compare the output against the versions listed in the Patched kernels table above.

Resolution

Once the patched kernel is installed:

Reboot into the patched kernel.
Verify the running kernel version:

uname -r

Remove the mitigation sysctl file:

sudo rm /etc/sysctl.d/cve-2026-53362.conf
sudo sysctl --system

Confirm user namespaces are re-enabled:

sysctl user.max_user_namespaces