Executive Summary
Four kernel privilege escalation flaws disclosed on 18 September matter less for their individual severity than for where they sit. All four live in ordinary, widely enabled networking subsystems, and the worst of them needs neither an unprivileged user namespace nor any capability to reach root. Anywhere SCTP diagnostics are enabled, a container is the shortest path, and the researcher rates two of the four as remotely reachable under narrow conditions. The disclosure landed with working exploit code attached.
The finding that should travel furthest is that AppArmor and SELinux both failed to block the reported exploit paths. A kernel flaw sits beneath the container isolation most platform teams treat as their security boundary, so a shared kernel carries more risk than the workload policies above it suggest. Fixed kernels already exist. Node recycling, not patching, is the slow part.
Four Linux kernel privilege escalation bugs went public on 18 September at 0600 UTC. Two of them are reachable from inside a container, and every Kubernetes node runs the affected code.
The researcher who found them, Asim Viladi Oglu Manizada, reported them to the kernel security team in mid-July. The fixes have been landing in stable kernel trees since. The public disclosure went out today with working exploit code attached.
The four are DirtyAH6 (CVE-2026-80844), TUNderflow (CVE-2026-81000), PPPoEject (CVE-2026-68121), and DiagSpill (CVE-2026-74469). The oldest bug has sat in the kernel for 21 years. None of them live in exotic code. They sit in IPv6 IPsec, TUN/TAP virtual networking, PPP over Ethernet, and SCTP diagnostics.
DiagSpill Is the One to Patch First
An SCTP association tracks its peer count in a 16-bit field. Add the 65,536th unique peer and the count wraps to zero. The sock_diag interface then reserves an empty payload and writes roughly 8 MiB of peer addresses past the end of the response buffer. The kernel CNA rates it 8.8 High.
What DiagSpill does not need is the part that should worry platform teams. No unprivileged user namespace. No capabilities. If SCTP and sctp_diag are available, the path is open. The other three need unprivileged user namespaces or CAP_NET_ADMIN, and plenty of clusters grant those to CI runners and shared namespaces without a second look.
Two of the four are not purely local problems either. The researcher describes DirtyAH6 and DiagSpill as remotely reachable under narrow conditions, and one of them as theoretically groomable all the way to remote root. That does not make every exposed node exploitable tomorrow. It does mean the usual assumption that a kernel privilege escalation needs hands on the box deserves a second look in any cluster that speaks IPv6 IPsec or runs SCTP.
SELinux Was Not Enough
Mandatory access control did not close the gap. AppArmor and SELinux both failed to block the reported exploit paths during testing. That is the uncomfortable finding. Isolation is a stack of assumptions, and the kernel sits under every one of them. It matches the shape of the containerd CRI flaws patched earlier this month, where the newest layer kept trusting metadata it should not.
A full container escape is theoretically possible with these primitives, though the researcher did not demonstrate one. Unprivileged local root on a node is already a bad afternoon.
The Patch Is Easy. The Reboot Is Not.
Fixed kernels are already out. The first stable releases carrying all four fixes are 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.109, 6.18.50, and 7.2.4. Managed fleets will roll them out on their own schedule. Node recycling lags the update, so a cluster that reports itself current can still run the vulnerable kernel for weeks. Self-managed clusters wait on whoever owns the upgrade window.
Triage comes down to reachability. Ask three questions of each cluster. Does it allow unprivileged user namespaces. Are SCTP and sctp_diag present. Does anything outside the trust boundary speak the protocols involved. DiagSpill needs no namespace and no capability, so a node with the SCTP diagnostics interface reachable is the one to patch first, whatever its container hardening looks like.
The disclosure itself was orderly. The researcher reported to the kernel security team in mid-July, the fixes moved into the stable trees over the following weeks, and the writeup and exploit code went out on 18 September under a coordinated embargo with the distribution list. Vendors had a patch to ship before anyone could read the details. Operators get no such grace, because the working exploit code is public now.
You cannot patch a kernel with a container image. Check what your nodes actually run, then re-check the assumption that a shared kernel is enough isolation for workloads you do not fully trust.
Get the next one before it is old news
Independent analysis of cloud-native infrastructure, Kubernetes and data centre economics. No vendor spin.