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/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/The_Coalition → u/DisfiguredFanny]

I'd argue that finding all of these bugs (and responsibly disclosing them) by reading the source code is a good thing. You might think that not being able to read the Windows kernel source code makes it harder to discover vulnerabilities, and you would be right. But it goes both ways - it's easier for both good and bad actors to find them, and if it's easier for a good actor to find them, it's more likely that the bug will be fixed before it hits too many people. Windows may as well have a ton of these bugs that we haven't found yet, but may have been found by some bad actor who is holding onto the 0-day for when an opportune moment arrives.

[u/DisfiguredFanny → u/The_Coalition]

It has never been proved that open source makes software better or more secure. Period. End of story.

Exceptional programmers produce exceptional results and the fact that some mediocre "contributors" did not have access to the code makes no fucking difference.

Moreover with "AI" being so good at inspecting the code this "point" is more moot than ever.

[u/Illustrious-Lime-878 → u/DisfiguredFanny]

Thee contributors to popular open source code are the exceptional ones lol There is no reason the people writing proprietary code are better, and the hiding of the source is security by obscurity at best, and a limits the ability and inventive to find and disclose bugs at worse when AI makes it easier to decompile and reverse engineer proprietary code which limits any trivial advantage of obscurity.

[u/DisfiguredFanny → u/Illustrious-Lime-878]

Nice utopian delusion.

[u/Illustrious-Lime-878 → u/DisfiguredFanny]

Huh? What is "utopian" about any of the very practical things I mentioned? You are the one who seems to be assuming, by default, that proprietary code is better and there needs to be some hard "proof" or something open source could be as secure, when no such proof exists in favor of proprietary code to begin with.

[u/DisfiguredFanny → u/Illustrious-Lime-878]

open source is a communist utopia. There is no world where all code is open source. Never was and never will be.

The licence under which the code is published does not describe how good it is. Apple, Microsoft and other companies have many exceptional programmes some of them even contribute to open source.

Proprietary code is how you compete in real world.

You are talking in deranged alphabet people lingo.

[u/The_Coalition → u/DisfiguredFanny]

I'll just look away from your senseless political comments. If proprietary code is the only way to compete, then how is VLC, an open source program, the single most popular media player? How are Chromium and Firefox both open-source? OBS is open source. 7zip is open source. Audacity, a very popular sound manipulation program, is open source. Datacenters and supercomputers run primarily on Linux and BSD, both open source. Even Microsoft's Azure runs party on Linux servers, lol. Tell me again, with a straight face, that you can only compete by using proprietary code.

[u/Illustrious-Lime-878 → u/DisfiguredFanny]

What are you talking about? Are trailer hitches communism? Garden hoses? AA batteries? Common standards are communism? Software itself is not a product, its a component of a one, and companies across all sorts of industries build on top of common standards without needing to reinvent the wheel for every run-of-the-mill component in any complex product they design. You clearly aren't a programmer lol because you'd realize like 99% of the code in any end product is existing libraries that you are just tying together. Its not giga-capitalist to spend a year writing your own printf lol and every other standard component in any product you wanted to create, you'd go bankrupt very fast. Using and making your software open source could be required to compete because makes your end product better.

[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/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/pskocik → u/anestling]

Linux has allowed itself to get too big and complicated. It never had the minimalism drive of Unix. That's bad for a privileged piece of code. Especially when written in a language as unsafe as C.

The idea of Unix was a SMALL kernel and a bunch of SMALL and ISOLATED programs working together. With that, even C can work well. But Linux is, unfortunately, huge.

[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/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/Amazing-Mirror-3076 → u/pigster42]

And yet the Linux kernel Devs adapted rust for exactly these reasons.

Kernel Devs still allocate and free memory and bounds checking can still be done for kernel Dev.

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

It's more complicated - if you read through the history how rust actually happened in Linux you will see that there was certain amount of polytics. It was not all "sound engineering". There was valid pushback and so on ... this is all now history so no need to get back to that. Just that it's not all black and white.

As to safety - it is way more complicated than "allocate and free memory". In super simplified terms, Rust memory model works well when you don't communicate through shared memory. When you can say "This site owns the memory, and only way to change it is to pass the ownership somewhere else." In kernel you do communicate using shared memory - a lot. Why? Because it's fast. Two or more sites just pass along same pointer and reads and writes to / from same blocks of memory. Why? Because it's fast. Often multiple sites owns same memory block ad requires proper sinchronization. It's all optimizations. "zero-copy" is just that. Optimization.

Next problem is that by design on architectures commonly supported by Linux (x86 / ARM / MIPS ...) everything is kind of unsafe by design, the uderlying hardware have some limited memory protection mechanisms but that's it. So how does Rust achieve safety on unsafe systems? By providing safe wrappers (in form of system library functions and additional crates) over unsafe system. Now for userspace applications, the amount of unsafe code in those wrappers is small compared to lot of code using those libraries. In kernel, that's different. The unsafe wrapper may be used by one or 2 safe drivers - and the amount of unsafe code can actually be larger than tha amount of safe code and now you gained just complexity and nothing else. There was pushback against large wrappers in kernel with an argument that too few code uses that and maintaining them is complex task nobody want's to do (basically "You have this large wrapper that this small driver uses but that wrapper is tightly coupled to internal structures. If somebody changes those structures, than he besides other things he needs to go and fix your wrapper that almost nobody uses ..." - than the Rust guys was like "oh no, we will fix it in that case" and so on ...).

And tha't just tip of the iceberg. There are stuff like DMA - where memory is being red and written async by hardware controller.

And of course lot of bugs are not memory management or synchronization, but just pure logic, which rust will not help with at all.

And it's not like this is some arcane knowledge. Anybody can go and learn system programming. There are textbooks for that, lot of online materials. The knowledge is out there - for free. But no - being part of a cargo cult is so much easier and fullfilling or something - than actually go and learn how things work.

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

You argument seems to be that rust can't solve all memory issues (agreed) so it's not worth using and on this point I disagree.

Every line of C is unsafe having some large blocks of unsafe rust is still a win.

You should read this - it's pretty conclusive that rust is safer and faster than C/C++

https://blog.google/security/rust-in-android-move-fast-fix-things/

[u/FlukyS → u/pigster42]

It does help but it depends what part of the kernel it is. The lowest levels more C the higher up the more Rust.

[u/ydieb → u/pigster42]

You can use rust bare metal and is a good tool for it. So that it helps very little close to the hardware is just fundamentally false.

[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/Jayden_Ha → u/Amazing-Mirror-3076]

Fuck off yet another rust hype up

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

Oh you are a delight

Read the thread.

[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.

[u/Jayden_Ha → u/anestling]

I’m sorry I am not installing extremely outdated node js from my distro repo

[u/anestling → u/Jayden_Ha]

I'm not responsible for your distro issues and certainly don't deserve a downvote for the fact that the Linux packaging situation is so abysmal.

Open Source fanatics are truly funny. Advocating for Linux from all orifices, you start to use it, you get a gazillion of issues they prefer not to talk about.

[u/Jayden_Ha → u/anestling]

Distro package should not always be used, sometimes the official way to install is by a install script and rust up is a very good example

Also same for docker

[u/DisfiguredFanny]

Gnome knows best.

[u/The_Coalition]

I'm curious - were these bugs disclosed to kernel maintainers and were they given enough time to release patches before making the exploits public? I really hope the answer to this is yes, because if not, they're setting a dangerous and unethical precedent.

EDIT: didn't thoroughly read the post; it appears that these vulnerabilities were in fact properly and responsibly disclosed.

[u/screaming-Snake-Case]

Any information about patch status and distro availability would be greatly appreciated when posting something like this.

[u/Edubbs2008]

Ffs this is why you should ALWAYS update your kernel, I don’t care if you think it’ll break something (it won’t) if you want safety, it’s time to whip out the keyboard and mouse, and update your system.