CISA says attackers are exploiting a Linux IPv6 kernel flaw that can give a local user root and, on affected RHEL 10 systems, escape a container.2026-08-29T15:34:36.168Z5 min2026endpointcloud
5 min read
Read format

CISA Flags Exploited Linux IPv6 Flaw That Lets Local Users Gain Root

CISA says attackers are exploiting a Linux IPv6 kernel flaw that can give a local user root and, on affected RHEL 10 systems, escape a container.

By Justin Howe
A Linux server rack with one network fragment crossing from a container boundary into the host kernel.

CISA added CVE-2026-53362 to its Known Exploited Vulnerabilities catalog on August 27, giving U.S. federal agencies until August 30 to remediate it. The Linux IPv6 kernel flaw is locally triggered. It gives an unprivileged process a route to kernel memory corruption and privilege escalation. On affected Red Hat Enterprise Linux 10 container hosts, that path can end in a container escape and root access.

The KEV entry is the newly actionable fact. CISA does not identify the exploited targets, victim count, or attack chain, and lists ransomware use as unknown. The public technical record shows that a remote IPv6 peer cannot directly trigger the flaw because the attacker must control a local UDPv6 socket and its send operations.

Known exploitation changes the deadline

CVE-2026-53362 sits in the Linux kernel’s IPv6 transmit path. CISA says it can affect multiple products, including SUSE, Red Hat, and other products built on Linux, but the agency does not quantify exposed systems. Its three-day federal remediation window makes vendor build verification urgent even though the observed campaign remains undisclosed.

Red Hat calls the issue ipv6_frag_escape and rates it Important. The vendor says a user with local access inside a container “could escape to the host, bypassing SELinux enforcement, and gain system administrator (root) access.” Red Hat lists RHEL 10 as affected and says all fixes are released. OpenShift Container Platform is not affected because it runs on RHEL 9.

That scope prevents two common mistakes. Internet exposure alone does not establish reachability because the trigger is local. A container boundary also does not contain the consequence when an untrusted workload can create the namespaces and sockets needed to reach the host kernel.

A fragment gap corrupts kernel metadata

The vulnerable code is __ip6_append_data() in net/ipv6/ip6_output.c. A local process opens an ordinary IPv6 UDP datagram socket, corks a datagram with MSG_MORE, and supplies pages with MSG_SPLICE_PAGES. When the datagram crosses a fragment boundary, the kernel carries bytes from the previous socket buffer into the next one as fraggap.

On the paged-allocation branch, the vulnerable calculation includes fraggap in datalen and pagedlen without reserving those bytes in the linear allocation. The copy then extends past skb->end into skb_shared_info, which holds fragment metadata and pointers used later by the networking stack.

Wongi Lee’s disclosure to oss-security, written with credit to Jungwoo Lee and Sultan Alsawaf, describes a controlled 15-byte overwrite. The researchers used it to change nr_frags, making stale frags[0] metadata available to the kernel as an allocated fragment. They assessed the primitive as exploitable for local privilege escalation. The IPv6 path requires CONFIG_IPV6=y.

Mechanism diagram showing a local UDPv6 splice crossing a fragment boundary, underallocating the next socket buffer, overwriting skb_shared_info, and reaching kernel privilege.

Figure details

An unprivileged local process controls an IPv6 UDP socket and sends a corked datagram with MSG_MORE and MSG_SPLICE_PAGES. Crossing a fragment boundary creates a nonzero fraggap. The vulnerable paged-allocation branch counts those carried bytes in datalen and pagedlen but omits them from alloclen, leaving the next socket buffer's linear area too small. The copy writes controlled bytes beyond skb->end into skb_shared_info. Corrupted fragment metadata provides a kernel-memory primitive that supports local privilege escalation and, in affected container configurations, escape to the host. Patched kernels add fraggap to alloclen, subtract it from pagedlen, and restore the negative-copy guard.

This path is distinct from a received network packet. The Linux CNA record scores the attack vector as local because a remote peer cannot set MSG_SPLICE_PAGES. It requires low privileges, no user interaction, and no race.

Affected kernels need vendor builds

Upstream Linux lists the minimum fixed releases as 6.1.177, 6.6.144, 6.12.95, 6.18.38, 7.1.3, and 7.2. Later releases on each maintained line supersede those fixes. The corresponding stable commits are 14200d435af9, 65fb14cbebb0, 46f201f8b4c3, 6374fb9edf72, e9eacf19281e, and mainline 736b380e28d0.

Distribution kernels carry backports, so an upstream version comparison by itself can misclassify a host. Operators should use the running distribution build and the vendor advisory as the decision point. The Debian tracker, for example, names 6.1.177-1 for bookworm, 6.12.95-1 for trixie, and 7.1.3-1 for unstable as fixed. Its current security builds, 6.1.180-1 for bookworm and 6.12.105-1 for trixie, supersede those minimums.

Red Hat’s temporary workaround sets user.max_user_namespaces=0, removing the unprivileged namespace capability needed for its documented container-escape path. Red Hat explicitly says this reduces exposure without repairing the kernel bug. It also breaks rootless Podman and some application sandboxes, so production owners need to test that operational consequence and prioritize the updated kernel.

Inventory namespaces before patching

Recognition starts with workload privilege. Inventory Linux hosts and container nodes where untrusted or lower-trust users can run local code, then capture uname -r, the installed distribution package release, and sysctl user.max_user_namespaces. Check IPv6 support with grep '^CONFIG_IPV6=' /boot/config-$(uname -r) when the distribution publishes its running configuration there. Map each observed build to its distribution advisory. Include build workers, shared shells, browser or application sandboxes, and container platforms that expose user or network namespaces to tenant code.

Patch with the vendor-supplied kernel and reboot into it. Record the previous and replacement kernel package, confirm the booted build with uname -r, and verify every maintained upstream line is at or beyond 6.1.177, 6.6.144, 6.12.95, 6.18.38, 7.1.3, or 7.2 unless a vendor documents a backport. For RHEL 10 systems using the workaround, the runtime check is sysctl user.max_user_namespaces; the expected result is 0. Keep the workload impact documented because that result does not prove the kernel is fixed.

The production verification test has two independent results: uname -r must report the approved vendor build after reboot, and a previously allowed unprivileged workload must be unable to reproduce the vulnerable namespace and UDPv6 preconditions or must run on the patched kernel. The expected result is a fixed running build on every in-scope host, with any temporary namespace restriction measured separately and removed only after the kernel update is confirmed.

KEV status supplies urgency without supplying incident scope. Defenders still need to prove which local-code surfaces could reach the kernel and which build is running after maintenance. A package transaction without the reboot leaves the exposed kernel in memory.

Primary sources

Continue reading

Article figurePinch or double-tap to zoom, then drag to pan.