New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Linux Kernel TCP RCE CVE-2026-98432
glueckself
Member
whelp, if that's what I think it is, it's over...
EDIT/more info:
Currently, Ubuntu is vulnerable, Debian is patched.
I expect a lot of Firewall/Router/... appliances are also vulnerable, if they have a public TCP port open on IPv4 (some VPNs, ...).
Thanked by 1WyvernCo
Comments
what do you think it is?
But it was fixed for trixie on 16th, wasn't it?
https://ubuntu.com/security/CVE-2026-98432
If you run Ubuntu 14.04 you are safe
A huge "fuck", as rpqu says.
At least for Ubuntu and everything not patched.
Uh. Thank god that's already taken care of. The upside of not using the usual suspects on my fleet
Yeah. I've just taken care of it by shutting down everything that runs Ubuntu and MikroTiks
It's not even Friday yet (at least here).
"This vulnerability (CVE-2026-98432) was patched upstream and backported to all maintained stable kernel branches."
but it's not fixed by Ubuntu, Red Hat etc.
There's more funny things here: https://www.anthropic.com/research/discovering-vulnerabilities-with-claude like one click exploits in Safari, Chrome, Windows Remote DDOS etc.
Anthropic liklely tried to pump their struggling business and IPO by another groundbreaking news, but seriously, this is getting little ridiculous.
Yes, Microsoft and Apple also want to spy on Russia, and then they'll go after the whole world.
This is just the beginning, guys. The hypervisor needs to encrypt the qubes; otherwise, we'll have to start hosting our own services from home if trust continues to erode.
At this rate, we'll eventually end up creating hardware integrated directly into the network adapter that blocks incoming and outgoing requests from your computer.
It will give you control over which IP addresses can connect to your computer and which IP addresses are allowed to send information out. You could configure it to only allow information to come in while never allowing information to leave, or, if it does leave, only permit specific data to be transmitted.
You would no longer depend on software or a traditional firewall. By controlling the network adapter itself, you control the gateway to your entire system.
If someone hacks the BIOS or discovers a vulnerability in the RAM or processor, they would first have to bypass the security built into the network adapter. This could serve as an additional layer of protection against the AI-powered surveillance they want to integrate into operating systems.
nvm
Fixed in Debian and Oracle Linux, that was fast, but not yet in Ubuntu. ElRepo kernels fixed too.
Someone it trying to make it a bigger deal than what it actually is.
Why does it seem like every CVE now-a-days is made out to be like "omg, it's over"
Don't get me wrong, high scoring RCEs are bad, but it's not the first and it won't be the last...
It has to be, where would the joy otherwise be?
Yeah, I'm sorry for starting the thread so dramatically.
On the other side, I really don't understand why it isn't like putting a pre-SP3 Windows XP without AV/Firewall on the net back in the days (being compromised in ~10min).
now the question is, is it even enabled in your kernel that youre using of the accessible devices? If its not, its certainly mood. My crap all has it enabled, but is on 6.18.59, so whatever. The otherone is compiled without it. So no reason to even bother thinking about it.
Now router could certainly be a funny one
I'm not sure MP-TCP is necessary for this one, but I'm still waiting on detailed reports.
Other than that, there is nothing more specific necessary, just an listening socket.
One of my servers runs debian, and the other one the latest ubuntu lts. At this point I think AI will find vulnerabilities every week every where.
Found a LLM output with a PoC. https://github.com/sgInnora/innora-cve-research/blob/main/CVE-2026-98432/writeup.md
It says that it's hard to hit, as the window is only µs wide, but someone more knowledgeable than me can say more
Gotta keep pumping AI hype…
Remember the guy going over 100s of CVEs on his project only to find 95% were false positives or plain wrong, but the “tech media” and “tech pundits” on X/hackernews/reddit etc already blew it up as if the thing was untouchable.
Rampant social media, exploiting AI and proper experts being ignored, what else could go wrong? Expect a lot more BS all around us in near future.
Supposed mitigation: https://github.com/typhoon1217/cve-2026-98432-mitigation
Because this particular one is bad, and ever since Heartbleed, vulnerabilities have gotten their own PR teams.
Maybe an ebpf filter could be used to mitigate this like it was done with copyfail?
Or set
net.mptcp.enabled = 0and use nftables to drop onip protocol tcp ip hdrlength gt 5in prerouting.Yup. Gonna scan for the vuln. Anyone handling IoT is fucked.
Ubuntu is such a steaming pile of shit, that they didn't manage to patch it in 13 14 days.
it's actually funny that debian already patched it. so much for being 'slow' distro
Slow as in getting "latest" packages long after their prime, not in patching vulnerabilities.
I checked on proxmox, since they're using a Ubuntu kernel. They did have it committed in code as proxmox does have the fix
why is redhat always late with patches? nothing here yet https://access.redhat.com/security/cve/cve-2026-98432
The flaw is a race condition in the code that sets up new IPv4 TCP connections.
We disabled IPv4 long ago except on VirMach.
VirMach hasn’t performed the Pwnscape reboot, so it can’t get worse.
Have you considered triggering it to solve that problem?