Eighteen years of wrong arithmetic in fragment reassembly: CVE-2026-80590
Published by RodHat

There is a one-line arithmetic error in __ip6_append_data() that has been sitting in the
kernel since Linux 2.6.27. That version shipped in 2008. The function undersizes a socket
buffer’s linear head by fraggap bytes during IPv6 fragment output, so a subsequent copy
operation overflows into skb_shared_info at the allocation tail. Heap corruption. Eighteen
years of it.
CVE-2026-80590. Affecting Linux 6.6 through 7.1 in the exploitable form. An identical bug
lives in IPv4’s __ip_append_data(). Both fixed in the same patch.
The punchline is the exploit chain. A process inside a network-isolated container, holding no
privileges worth mentioning, crafts the right fragments through a TUN/TAP interface. GSO state
on the fragment survives reassembly because the kernel was keeping wrong notes about it. That
incorrect metadata eventually hits software segmentation and triggers a BUG condition. But
before the panic, if you control the right race and the right heap layout, nr_frags in the
packet metadata is yours to write. From there: use-after-free on an attacker-controlled page,
reclaim it as a page table entry, arbitrary kernel read/write, hijack core_pattern,
interactive root shell in the host’s initial namespaces and root filesystem.
A public PoC is circulating. The five-stage chain above is not theoretical.
The affected range is essentially every distro kernel shipping in production right now. If you are running containers on Linux, you want to look at this today. Container hosts, shared hosting, CI runners, multi-tenant environments: the attack crosses the isolation boundary. Understanding what Linux namespaces actually isolate is relevant context if you have been assuming “container” meant “protected.”
What shipped
Greg Kroah-Hartman pushed eight stable kernels specifically for this CVE: 7.2.2, 7.1.12, 6.18.48, 6.12.107, 6.6.155, 6.1.186, 5.15.219, and 5.10.268. Single-fix releases. He does not typically dedicate a coordinated eight-branch drop to one bug. When he does, read the bug.
The fix adds fraggap to the linear buffer allocation and subtracts it from the paged portion.
The head is properly sized. The overflow is gone. Both IPv6 and IPv4 paths get the same
correction. Not a rethink of the architecture, just arithmetic that was wrong for eighteen
years, finally right.
The 2.6.27 footnote
The code was introduced in 2.6.27. The exploitable window for the container escape is narrower, 6.6 onward, when the relevant subsystem components lined up into the configuration the PoC requires. So the arithmetic was broken for a long time before it became dangerous in this particular way. That is not reassuring. It is just accurate.
The same thing is happening on the eBPF side: every widened unprivileged attack surface eventually produces a paper like this one. The eBPF unprivileged lockdown post from August covers the parallel argument.
What to do
If you are on a distro and your last kernel update was before late August, update. The PoC is public; the gap between “patched” and “exploited against unpatched systems” is now measured in days, not weeks.
If you run a vanilla kernel, the patched stable releases are above. Pick the one that matches your branch, rebuild, reboot. There is no clever mitigation for a heap overflow in the packet fast path.
The September 7 stable release covered the third stable drop of the past two weeks. If you are the person who decides when boxes get rebooted, this is a bad time to let the queue back up.