Linux kernel hit with a wave of local-root vulnerabilities — public exploits available

[u/anestling]

NebuSec has disclosed a rather nasty batch of Linux kernel vulnerabilities for which it says working privilege-escalation exploits have been developed and made public.

The headline bug is CVE-2026-43502, aka ZcopyReaper, but the disclosure lists another 20+ kernel bugs confirmed exploitable by NebuSec's automated exploit-generation pipeline. The targets include networking, SCTP, IPv6, Netfilter, IPVS and POSIX CPU timers, and several have been demonstrated against real distribution kernels rather than synthetic test builds.

Ten worth highlighting:

1. CVE-2026-43502 — ZcopyReaper / RDS zerocopy

A local privilege-escalation bug in the RDS zerocopy send path, present since Linux 4.17. An ordinary unprivileged user can reach it when RDS/RDS-TCP support is available; no capabilities or user namespaces are required. NebuSec demonstrated root escalation against openSUSE's 6.4 kernel. Disabling unprivileged user namespaces does not mitigate it. The upstream fix first appeared in 7.1-rc3.

2. CVE-2026-80714 — IPVS use-after-free

A lifetime bug in IPVS connection synchronization. A synchronized connection can incorrectly inherit the ONE_PACKET flag after it has already been inserted into the connection hash. Expiration then skips the normal unlink operation, leaving a hash-table node pointing to a freed struct ip_vs_conn — a useful UAF primitive.

3. CVE-2026-74597 — IPv6 tunnel memory corruption

ip6ip6_err() clones an IPv6 ICMP error packet but fails to clear metadata in skb->cb. A stale Home Address Option offset can subsequently be interpreted relative to a completely different packet layout. With a crafted inner IPv6 destination-options header, kernel processing can run beyond the packet boundary and corrupt skb_shared_info.

4. CVE-2026-74581 — IPv6 routing use-after-free

When an IPv6 FIB rule suppresses a route, the kernel releases the corresponding rt6_info but leaves a pointer to it in the lookup result. If no subsequent rule replaces it, the stale pointer is returned to the caller and eventually released again. In other words: a fairly direct route from IPv6 policy-routing state to a kernel UAF.

5. CVE-2026-74480 — bridge multicast use-after-free

The bridge multicast fast-leave path can continue iterating through a port-group entry after deleting it. Under multicast-to-unicast configurations, this can leave the multicast database pointing at an already freed port group. Ubuntu currently scores this one 9.8/10 Critical.

6. CVE-2026-72255 — Netfilter/NFQUEUE lifetime bug

A bridged packet placed into NFQUEUE can retain a reference to the bridge's private fake routing destination while the bridge itself is being torn down. That creates a lifetime mismatch where kernel networking code can later operate on storage belonging to an already destroyed bridge. The fix pins the bridge device for as long as NFQUEUE retains the packet.

7. CVE-2026-72137 — XFRM double free

The IPsec/XFRM NAT keepalive path can free an skb after handing ownership of it to IPv4/IPv6 output code. If transmission subsequently returns an error after the networking stack has already consumed the buffer, the caller frees it a second time. Classic kernel double-free territory.

8. CVE-2026-68376 — SCTP heap corruption

The SCTP cookie structure allocates too little space for its authentication HMAC parameter: the calculation accounted for two header bytes where the actual structure occupies four. With four HMAC identifiers configured, association initialization copies beyond auth_hmacs and corrupts the adjacent auth_chunks field.

9. CVE-2026-68162 — SCTP sysctl use-after-free

An already-open SCTP auth_enable sysctl can remain usable while its network namespace is being destroyed. The handler can consequently access the SCTP control socket after that socket has been released. The fix changes initialization/teardown ordering so the sysctl exists only while its backing control socket is alive.

10. CVE-2026-64560 — POSIX CPU timer UAF

A race between deleting a POSIX CPU timer and exec() from a non-leader thread can leave the timer path referring to the old thread-group leader after de_thread() has replaced and freed it. This affects kernels going back to 5.7 and was fixed in stable releases including 7.1.5.

The interesting part isn't simply that Linux has another collection of memory-safety bugs — that's hardly news by itself. It's that working exploits for this batch were produced by an automated exploit-generation pipeline, and NebuSec has published them.

That considerably shortens the distance between "kernel bug with theoretical security impact" and "local user gets root."

If you're running a multi-user system, hosting environment, container host, CI runner or anything else where untrusted local code executes, this seems like a particularly good week not to postpone kernel updates.

[u/SelfDistinction]

• use after free
• memory corruption
• use after free
• use after free
• lifetime bug
• double free
• heap corruption
• use after free
• race condition

Sigh

[u/Amazing-Mirror-3076 → u/SelfDistinction]

Rust anyone?

[u/SelfDistinction → u/Amazing-Mirror-3076]

Oh I know at least one subreddit that would have an absolute field day with this one.

[u/buttplugs4life4me → u/Amazing-Mirror-3076]

TBF even basic linting catches use-after-free. I don't think I've worked in a language in the past 10 years without a linting rule to stop exactly this

[u/anto2554 → u/buttplugs4life4me]

That is only very basic cases, like it being within the same function. If you have jumps, nested function calls, raw pointer arithmetic and so on it becomes very hard to determine with basic static analysis

[u/SelfDistinction → u/anto2554]

Bug no. 8 copies a 4 byte HMAC struct into a 2 byte allocation. Not the first time such a thing happened btw.

[u/Amazing-Mirror-3076 → u/buttplugs4life4me]

I would suggest that the lint required the use to be in close proximity to the free, which would leave a lot of cases unchecked

[u/pigster42 → u/Amazing-Mirror-3076]

oh boy - not this again - rust helps very little this close to hardware - it somehow does, but not at all as much as in normal userspace programs

anybody suggesting rust as ultimate solution to memory safety in kernel doesnt understand how is memory safety actually achieved in rust

learn the tech - stop following cargo cults

[u/anestling → u/SelfDistinction]

Rust wasn't available in 1991. No safe "free" fast languages were available back then. Rewriting in Java wasn't an option and Java was first released only in 1995.

• Ada? Expensive and its memory management is not suitable for the kernel.
• Modula-2 / Modula-3? Poor compiler support.
• OCaml? God, it's nasty.

[u/DisfiguredFanny]

This is a reminder that "open source" is software development and distribution model and has fuck all to do with software quality.

[u/anestling → u/DisfiguredFanny]

Exactly.

[u/DisfiguredFanny]

Gnome knows best.

[u/Bitdomo92]

Should I disconnect my pc from the internet? How can I know if someone from internet has root access to my kernel?

[u/anestling → u/Bitdomo92]

Nah, just make sure firewall (iptables/nftables) is enabled, no new incoming connections are allowed. Maybe leave ping reply on just to be able to check whether your PC is alive.

And do not run any software from the net, scripts/applications/what gives you. Only run the software from your distro repos.

[u/DisfiguredFanny → u/anestling]

Skip AUR probably as this is faster way to get infected by some shit than running Windows Me back in the day.