All blog posts

IPV6_FRAG_ESCAPE vulnerability fix: Call for testing

profile
Andrew Lukoshko

AlmaLinux Lead Architect

A new Linux kernel local-privilege-escalation flaw has been disclosed in the IPv6 fragmentation code, and it is serious: an unprivileged user inside a container can use it to escape to a root shell on the host. There is no CVE assigned yet, so for now we are referring to it as IPV6_FRAG_ESCAPE, the name its proof-of-concept uses. Only AlmaLinux 10 and AlmaLinux Kitten 10 are affected. A patched kernel for AlmaLinux 10 is available in the testing repository today, and we would like your help verifying it before we push it to production.

The flaw was discovered by security researcher Massimiliano Oldani during Google’s kCTF program, and a deliberately-incomplete proof-of-concept has been published on GitHub by sgkdev. Because the upstream fix reached mainline without a coordinated CVE assignment or a stable backport, the public patch effectively serves as a roadmap for a 0-day. With exploit code already in the open, this one matters today.

What the bug is

The bug is an arithmetic error in __ip6_append_data(), the function that assembles outgoing IPv6 packets. When a fragmented IPv6 datagram is built through a UDP socket using MSG_SPLICE_PAGES, the kernel undersizes its allocation and writes past skb->end into the trailing skb_shared_info, corrupting the nr_frags field. From there the public exploit chains that overflow into a page use-after-free, arbitrary kernel read/write, and finally a root shell in the host’s initial namespaces — turning an unprivileged user inside a container into root on the host.

Why only AlmaLinux 10 and Kitten 10? The vulnerable code path lives in the 6.12 kernel. AlmaLinux 8 (kernel 4.18) and AlmaLinux 9 (kernel 5.14) do not contain it and are not affected. The same upstream code is what makes CentOS Stream 10 and RHEL 10 vulnerable as well.

More information about the vulnerability:

Patching ahead of our upstream

Security is a top priority at AlmaLinux. The combination of how trivially this escalates to host root, the fact that working exploit code is already public, and the absence of any CVE or coordinated upstream fix for the RHEL/CentOS Stream kernel meant we did not want to wait. Our core team has backported and adapted the upstream __ip6_append_data() fix to the AlmaLinux 10 kernel. The decision to ship ahead of a CentOS Stream / RHEL update was made by our technical steering committee, ALESCo.

These kernels are available in the testing repository today. After the community has helped verify them, we will release them to the production repositories. This blog post will be updated when that happens.

Help us test

It only takes a few steps to install and test the patched kernel from the testing repo.

Install the testing repo

sudo dnf install -y almalinux-release-testing

Update the kernel

sudo dnf update 'kernel*' --enablerepo=almalinux-testing

Reboot to load the new kernel

sudo reboot

Confirm you are running the patched kernel

uname -r
rpm -q kernel

You should see kernel-6.12.0-211.28.2.el10_2 or higher.

We don’t recommend keeping the testing repo enabled after you’ve updated, unless you’ve done this on a truly non-production environment. If this is a production environment, you can disable the repo with this command:

sudo dnf config-manager --disable almalinux-testing

If you encounter problems, please let us know as soon as you can, either in AlmaLinux chat or on bugs.almalinux.org.

A note for AlmaLinux Kitten 10 users

AlmaLinux Kitten 10 is affected, but a patched kernel is not available for Kitten yet. The fix will arrive in the next Kitten kernel update. Until it ships, Kitten users should apply the temporary mitigation below. We will update this post once the patched Kitten kernel is available.

Affected versions and patched kernels

Only the AlmaLinux 10 family is affected:

  • AlmaLinux 10 is patched in kernel-6.12.0-211.28.2.el10_2 and above (available in the testing repository now).
  • AlmaLinux Kitten 10 is affected; a patched kernel is not available yet and will land in the next Kitten kernel update. Apply the temporary mitigation below in the meantime.

AlmaLinux 8 and AlmaLinux 9 are not affected and require no action.

Temporary mitigation if you cannot reboot yet

The public exploit relies on an unprivileged user namespace to obtain the network capabilities it needs to craft the malicious IPv6 packets from inside a container. On systems that do not legitimately need unprivileged user namespaces, you can sharply reduce the attack surface by disabling them:

sudo sysctl -w user.max_user_namespaces=0

To make it persistent across reboots:

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

Be aware of the trade-off: rootless containers (rootless Podman, unprivileged LXC, some sandboxing in browsers and CI runners) depend on unprivileged user namespaces and will stop working while this is set. If those workloads matter to you, do not apply this mitigation — install the patched kernel and reboot instead. To revert, remove /etc/sysctl.d/99-ipv6-frag-escape.conf and set the value back with sudo sysctl -w user.max_user_namespaces=<previous value> (the default is a large positive number).

The proper fix is the patched kernel. The mitigation is only a stop-gap for hosts that cannot reboot immediately.

Thanks

Thanks to Massimiliano Oldani for finding and writing up this vulnerability, and to sgkdev for the public proof-of-concept and analysis that made it possible to understand and verify the fix.

Thanks as well to the AlmaLinux core team for turning around a patched kernel quickly, and to ALESCo for moving to approve shipping ahead of upstream. And thank you in advance to everyone in the community who helps us test these kernels — that’s the part that gets them safely into production.

Stay informed

Remaining aware of these vulnerabilities and acting quickly can keep your system and data safe. Follow the AlmaLinux Blog, join the Mattermost Community Chat, and subscribe to the Announce and Security mailing lists to stay informed. We will update this post when the patched kernels move from testing to production.

Bleiben Sie auf dem Laufenden!