19 Public Root Exploits in Two Days. Seven Have No Fix on a Longterm Kernel.

On the morning of October 22, 2026, Google merged thirteen new exploit write-ups into the kernelCTF section of its security-research repository. The next morning it merged six more. kernelCTF is Google’s bounty programme for Linux kernel privilege escalation: a submission only lands there after it has taken a hardened Google Container-Optimized OS or mitigation instance from an unprivileged process to root. Every one of the nineteen ships with a working exploit and a write-up of what it needs.

Seventeen of the nineteen CVEs had no kernelCTF exploit before those two mornings; the other two already carried one from an earlier kernelCTF entry. KernelScan has picked up both batches, and all nineteen are flagged Weaponized on every product that tracks them. Two of the entries are for 2023 CVEs — a reminder that the public exploit can arrive years after the fix. The more pressing finding is a different one: for seven of these CVEs, at least one still-maintained longterm kernel has no fix in any release.

The nineteen

CVE	Subsystem	Bug	What the exploit needs	CVSS	Longterm fix
CVE-2026-23272	nf_tables sets	UAF (RCU)	user namespace, NF_TABLES	7.8	none on 5.10, 5.15
CVE-2026-31419	bonding broadcast	double free	user namespace, BONDING	7.8	none on 5.10, 5.15
CVE-2026-23231	nf_tables chain creation	UAF (RCU)	user namespace, NF_TABLES_INET	7.8	none on 5.10, 5.15
CVE-2026-23392	nf_tables flowtables	UAF (RCU)	user namespace, NF_FLOW_TABLE_INET, NETFILTER_INGRESS	7.8	none on 5.10; 5.15 queued
CVE-2026-23278	nf_tables catch-all elements	UAF	user namespace, NF_TABLES	7.8	none on 5.15
CVE-2025-38248	bridge multicast	UAF	user namespace, BRIDGE_IGMP_SNOOPING	7.8	none on 5.15; 6.1 queued
CVE-2024-26583	kernel TLS	UAF (race)	no namespace; TLS + async crypto	4.7	none on 5.10
CVE-2025-40214	AF_UNIX garbage collector	UAF	nothing but CONFIG_UNIX	7.8	all fixed
CVE-2026-43501	IPv6 RPL routing header	out-of-bounds write	user namespace, IPV6	9.8	all fixed
CVE-2026-31418	ipset hash sets	out-of-bounds write	user namespace, IP_SET hash types	5.5	all fixed
CVE-2026-23274	xt_IDLETIMER	uninitialised timer	user namespace, NETFILTER_XT_TARGET_IDLETIMER	7.8	all fixed
CVE-2026-23111	nf_tables catch-all	UAF	user namespace, NF_TABLES	7.8	all fixed
CVE-2026-23209	macvlan	UAF	user namespace, MACVLAN, PACKET	7.8	all fixed
CVE-2026-23273	macvlan (follow-up)	UAF	user namespace, MACVLAN	7.8	all fixed
CVE-2026-23074	tc teql qdisc	UAF	user namespace, NET_SCH_TEQL	7.8	all fixed
CVE-2025-38177	tc HFSC/QFQ/netem	UAF	user namespace, three qdisc modules	5.5	all fixed
CVE-2025-21702	tc pfifo_head_drop	UAF	user namespace, NET_SCHED	7.0	all fixed
CVE-2023-3610	nf_tables bound chains	UAF	user namespace, NF_TABLES	7.8	all fixed
CVE-2023-31248	nf_tables chain lookup	UAF	user namespace, NF_TABLES	7.8	all fixed

“Longterm fix” covers the kernel.org longterm lines that carry the vulnerable code: 5.10, 5.15, 6.1, 6.6 and 6.12. “Queued” means the backport is in the stable maintainers’ queue for the next release of that branch, but no release carries it yet. CVSS is the score shown on NVD: NVD’s own where it has scored the CVE, otherwise the kernel CNA’s. Status at analysis time, October 24, 2026, checked against the kernel CNA’s records, the current releases 5.10.272, 5.15.223 and 6.1.190, and the stable queue.

Seven with no longterm fix

The usual advice for a public kernel exploit is “update to the latest stable release of your branch.” For these seven, on these branches, there is no release to update to. We confirmed each gap the same way: the fix’s commit is absent from the branch, and the vulnerable code is still in its newest release.

Three nf_tables bugs, one mistake

Three of the seven fail the same way: an error path takes an object out of service and frees it at once, while a packet or reader that picked it up a moment earlier is still using it.

• CVE-2026-23272: a set element, freed when the set turns out to be full. The pattern dates from Linux 4.10 (2017). CIP’s own tracking shows fixes only for its 6.1 and 6.12 trees.
• CVE-2026-23231: a chain. The exploit fills the IPv6 hook table to its limit of 1,024, so an inet chain’s IPv4 hook goes live and its IPv6 hook fails.
• CVE-2026-23392: a flowtable, freed when a duplicate-device check fails after its hooks are live.

The fourth nf_tables gap, CVE-2026-23278, is a stray break. When a batch deletes a map and adds to it, the map briefly holds two catch-all elements, the helpers handle only the first, and a chain is freed while still in use. It reached 5.15 through a stable backport in 5.15.121. 5.10 has no catch-all elements, so neither this bug nor CVE-2026-23111 applies there, although the CNA record lists 5.10 as affected.

CVE-2026-31419 — bonding

A bond in broadcast mode gives the original packet to the “last” slave and clones it for the rest. Adding or removing a slave mid-loop changes which one is last, and the packet is freed twice. The bug reached 5.10.94 and 5.15.17 in January 2022 through a stable backport. The mainline fix relies on a slave count the older code never computes, so a backport needs adapting.

CVE-2025-38248 — bridge multicast

Deleting a port can leave it on the bridge’s list of multicast-router ports, and the next walk over the list uses freed memory. The variant the exploit uses arrived in 5.15.186 and 6.1.142 with a stable backport on June 27, 2025; a sibling variant has been in both branches since 5.15. IGMP/MLD snooping with VLAN filtering (CONFIG_BRIDGE_IGMP_SNOOPING) is what many switches and gateways ship. The 6.1 fix was queued on October 18; nothing is queued for 5.15.

CVE-2024-26583 — kernel TLS

With asynchronous decryption, the crypto callback wakes the waiting thread before it drops a lock in the socket context. If the socket is freed in that gap, the unlock writes into reused memory. 5.15 got the fix in 5.15.160 (May 2024). 5.10.272 still calls complete() before spin_unlock_bh() in tls_decrypt_done(). It is the only gap that needs no user namespace.

Seventeen of the nineteen share one front door

Seventeen exploits get CAP_NET_ADMIN the same way: an unprivileged process creates a user namespace and, inside it, a network namespace of its own, where it can configure nf_tables, qdiscs, bridges, bonds and macvlan devices. The host does not need to use any of these features. The code only has to be built in or loadable.

Ways to switch it off: user.max_user_namespaces=0, Debian’s kernel.unprivileged_userns_clone=0, Ubuntu’s AppArmor restriction on unprivileged user namespaces, or building without CONFIG_USER_NS.

The two that still work need only a local shell. CVE-2025-40214, in the AF_UNIX garbage collector, needs nothing but CONFIG_UNIX. It reached 6.1.141 and 6.6.93 through a stable backport and is fixed in 6.1.159, 6.6.117 and 6.12.59. The other is kernel TLS, above.

It is not a complete answer. Any process that already holds CAP_NET_ADMIN (a container started with it, a networking daemon, a management agent) reaches the bugs without a namespace. And browsers, container runtimes and sandboxes rely on user namespaces, so a general-purpose host often can’t turn them off. On a sealed appliance that runs no untrusted local code, the trade-off looks very different.

The scores point both ways

• CVE-2026-31418 and CVE-2025-38177 are scored 5.5 by NVD, as local denial of service with no confidentiality or integrity impact. The kernelCTF entries describe an out-of-bounds write in the ipset hash code and a use-after-free in the HFSC/QFQ qdiscs, and both exploits turn them into root on a hardened instance. A queue sorted by CVSS puts them behind every High.
• CVE-2024-26583 gets two opposite scores. The kernel CNA rates it 9.8, network-reachable with no privileges. NVD’s own analysts rate it 4.7, a local denial of service. The published exploit sits between the two: it is local, needing a shell on the box to open TLS sockets and race their teardown, and it gets root. It is serious because it needs no namespace and is unfixed on 5.10, not for the reason either vector suggests.
• CVE-2026-43501 is scored 9.8 by the kernel CNA, as a remote bug with no privileges. The code is in the IPv6 receive path, but it only handles RPL source-routing headers when net.ipv6.conf.all.rpl_seg_enabled and the interface’s own setting are both 1. Both default to 0. The published exploit turns them on inside its own network namespace, so in practice it is one more user-namespace exploit. A remote attacker can only reach the bug on hosts where someone switched RPL processing on, such as 6LoWPAN mesh routers. It is fixed on every longterm line.

None of these numbers is useless. Each describes the bug in the abstract. What decides your priority is whether the code is in your build and who can reach it.

Triage by product type

• Multi-tenant hosts, CI runners, shared build machines: unprivileged user namespaces are usually on. All nineteen are in play wherever the code is unpatched. Treat the seven unfixed longterm cases as backport work now.
• Container hosts: check which workloads run with CAP_NET_ADMIN. They reach the seventeen namespace-gated bugs directly, whatever the host’s user-namespace setting.
• Switches, gateways and routers on 5.15 or 6.1: CVE-2025-38248 is the one to check first: multicast snooping is common on these devices, and there is no stable fix yet (6.1 is queued, 5.15 is not). The attacker still needs local code execution plus a way to CAP_NET_ADMIN.
• Embedded and industrial devices on 5.10 or 5.15: these branches carry most of the gaps — five on 5.10, six on 5.15. If nf_tables is built in, look at the nf_tables group first; then bonding, and kernel TLS on 5.10. If your product can switch off unprivileged user namespaces, that closes every gap on these branches except kernel TLS on 5.10.
• Sealed appliances with no untrusted local code: all nineteen are local privilege escalations as published. They matter as the second stage after another bug gives an attacker code execution — which is exactly how real attack chains are built, so “local” is not the same as “ignore”.

How KernelScan helps

Upload your kernel .config and KernelScan answers the question per CVE: is the code in your build, is it reachable, and is your branch’s release already carrying the fix? For the nineteen here that means the Weaponized badge on the ones you are exposed to, a Not affected verdict with the reason — for example CONFIG_BONDING not set — for the ones you aren’t, and the same verdicts in the CycloneDX VEX we push to Dependency-Track. Our earlier post on exploit maturity explains where the Weaponized signal comes from.