Hacker News

Quite, however it looks quite rare:

"Why it's urgent: the bug sits in code every Linux server runs when it accepts an IPv4 TCP connection, before any application sees the connection. Anthropic, whose researcher reported it, says its Claude model wrote a working proof-of-concept exploit that runs commands as root on "Linux servers with a multipath TCP listener," with no credentials. Go programs open those listeners by default, per the Go Security Team. See the timeline."

I don't know of any Linux boxes running a multipath TCP listener in my care and I have quite a few. MP generally implies a router of some sort and the intersections in a Venn diagram continue to get smaller ...

This is still an issue and must be patched but I think it will be rare, very rare.

"TCP stack" versus "Linux TCP stack" is an OOM in terms of relevance.

> Exploitability over the internet is unlikely, most ISP routers drop packets with ipoptions fields.

That doesn't track. Apple iPhones are a major user of MPTCP and they report the majority of requests supporting MPTCP, IIRC 70+%.

Dropping packets with IP options from XDP should be a more complete mitigation (also more performant).

Tragically not enough people drop IP options. I did it in the early 2000s for a very large US network and was glad. There's lots of obvious reasons as they're generally an old school ddos path to knock out routers (get punted to the RE/RP exception path, a good way to bypass some loopback/routing engine acls if folks don't filter it right). Every few years some academics pop up with let's use IP options because we can stuff more bullshit in the datagram - it's always a bad idea.

I'm wondering if Android is vulnerable, since it is based on Linux?

For more on why MPTCP is not relevant--my limited understanding is the issue is with SYN retransmits.

SYN packet #1 is received and added to a request queue for processing.

SYN packet #2 is received and is a retransmit of SYN packet #1. It is matched to SYN packet #1 already in the request queue and now there is shared state between both SYN packets #1 and #2 in the request queue.

CPU #1 takes on the task of processing SYN packet #1.

CPU #2 takes on the task of processing SYN packet #2.

CPU #1 responds back with RST packet #1 (e.g. requested TCP port is not open) and _should_ defer the destruction of the request socket for SYN packet #1, as other CPUs may still be processing the shared state for the request socket as is the case for retransmitted SYN packets.[1] However, this deferred destruction wasn't occurring, and CPU #1 was _immediately_ destroying the request socket/shared state for SYN packet #1.

CPU #2 races with CPU #1 and reads from the request socket/shared state for SYN packet #1 after its _immediate_ destruction by CPU #1.

Linux's IPv6 handling is unaffected because in this IPv6 scenario, there is no shared state between SYN packets #1 and #2 in the request queue. Instead, each request socket has duplicate data.

Someone more knowledgeable can confirm/correct me on the above please.

[1] https://www.kernel.org/doc/html/latest/RCU/whatisRCU.html#rc...

And it takes around an hour to do this in lab setting locally:

> An enabling property of this race condition is that a lost race only fails the handshake without crashing the whole system, so a determined attacker can retry indefinitely until they succeed. In our proof of concept, it takes 48 minutes to leak a kernel pointer and another five minutes to reach the shell command execution

source: https://www.anthropic.com/research/discovering-vulnerabiliti...

If you read commit logs of, say kernel.org and a distro kernel, and aren't concerned you are blissfully ignorant (and it is worse for the broader userland repos). It's particularly bad when they don't track a kernel.org LTS. Their kernel orgs are pretty lean and this has been the status quo for decades. CVEs of sufficient stature like this will get fixed but majority of other issues slip by unnoticed. LTS is kind of a myth, it trades ABI and API stability for a lot of other issues.

Given the current and rapidly upcoming environment, would that not imply that those are no longer viable choices? As like a fairly urgent emergency consideration?

If they cannot demonstate being systematically able to adapt towards the required reaction time (minutes? hours?) by almost-comically many orders of magnitude (multiple weeks), and it is only going to get worse, then what other conclusion could there be?

Like they'll only organizationally adapt when it's far too late (everybody using their shit has already been pwned), and then it'll be an unpracticed emergency adaptation.

> How are Ubuntu and RHEL not fixed?

Ubuntu has had kernels in the "proposed" component for several days now if you want to pull it in manually. Not yet pushed to "security" or "updates".

I’m pretty confused because apparently Anthropic is the group that followed “responsible disclosure” but apparently even though upstream was patched a couple weeks ago, still nothing on either.

It seems particularly crazy for Ubuntu given that Debian released their fix something like a couple weeks ago.

It's one of two things: Either they have found some regression with enterprise customers, or they are not happy with the fix.

RHEL runs with MP-TCP disabled by default, they initially listed it as Important only to later raise it to Critical.

I don't think I can recall an instance where there was an issue this bad (a box being vulnerable just by virtue of being connected to the internet, or exposing nothing other than ssh) and I didn't have timely patches for it. I had to turn off my server and home automation system because of this. Really not acceptable at all and makes me want to switch everything to debian.

Going by the proxmox forum the fix is already in the sources (proxmox released their kernel based on them a few days ago). But I could not see, if it is already released for the users.

https://forum.proxmox.com/threads/cve-2026-98432-in-proxmox-...

>How are Ubuntu and RHEL not fixed?

IMNSHO this makes them unfit for purpose. I think this is the nail in the coffin for Ubuntu for me.

Running regression tests I assume; they can't just YOLO shit like most OSS projects for the exact reason you mention.

Interestingly, Ubuntu Priority is set to "High" and not "Critical" which is defined as:

"A significant problem, typically exploitable for nearly all users in a default installation of Ubuntu. Includes serious remote denial of service, local root privilege escalations, local data theft, and data loss."

> https://ubuntu.com/security/CVE-2026-98432

The listed kernels are in the "proposed" component (and not yet in "security" or "udpates") if you want to pull them down onto canary systems for testing before going to production.

so just block multipath and add the firewall rule from article that drops packets with IPv4 options

I'm more worried about my consumer-grade router.

The timeline says the CVE was reported over 2 weeks ago, so why are the alarms sounding now?

Note: AWS NLB doesn't terminate TCP for TCP listeners.

It would be great if they introduced mitigations for this vulnerability though.

Another reason hyperscaler cloud providers will continue to grow (IMO)!

The fallacy is the idea that a Rust implementation would automatically achieve the same performance, and not resort to "unsafe" to be competitive, and then be open to exactly the same issues.

Illustrative example: This CVE in a Rust matrix transpose code: https://github.com/advisories/GHSA-5gmm-6m36-r7jh

Conceptually, there is not really anything much simpler than a matrix transpose. So how did they manage to create a bug? To make it fast you need simd, which implied using unsafe, and the dimension check to make it safe used unsigned integers that could wrap around. So they same bullshit as in C.

Counterpoint, more than memory bugs exist, and everything's written in C. You're welcome to rewrite in Rust but you'll create countless bugs that aren't memory bugs that mostly already got fixed in the C version. I can't help but think things like fil-C are the most pragmatic route, despite performance costs, for most people relying on programs written in C.

With all the "Claude rewrote X in rust!" posts lately, I'm waiting on the inevitable Linux kernel rewrite post.

Vibe code aside I feel targeted rewrites are becoming more and more justified.

https://pwn.watch/ has an RSS feed available

Any chance you’d mind sharing your list?

The openwall oss-security list usually covers a decent number of issues and this CVE was mentioned there yesterday:

https://www.openwall.com/lists/oss-security/

IoT devices will get fixes delivered on the 12th of never.

You should assume your IoT junk is already compromised, that's why your IoT junk runs on a dedicated VLAN.

I think fix arrived like two weeks ago or something. So typical Desktop Linux is safe. I use Arch btw

You need to do some https://en.wikipedia.org/wiki/Heap_feng_shui. If you can reasonably reliably trigger some other operation that allocated the freed memory for another purpose, you have something like a type confusion vulnerability.

Out of interest - what models are you using for this? GLM?

From experience OpenAI and Anthropic have pretty heavy safeguards in recent (public) models.

One example is that you might be able to read what was written there. Here that may mean you could read another process’s packet(s). Imagine they were sending unencrypted passwords, perhaps because it’s in a trusted LAN connection.

If it’s freed it can be reallocated, so then you have pointers to the same area of memory used for completely different data structures, and this can go very wrong

It goes around in circles because a UAF alone isn't enough in a lot of cases, sometimes you also need a chain (an info leak, read/write primitive etc), a way to defeat ASLR and so on depending on what you are working on and target mitigations. Not all UAFs can be used for RCEs, some can be used only for DoS or for nothing really.

been doing exactly this lately with camera firmware and yeah the circles thing is real, but im pretty sure its a feedback loop problem, not a model problem

the model spins because it cant test its own guesses. what fixed it for me was emulating the actual device. qemu with the vendor rootfs, real binaries running, and then every claim becomes checkable: did the daemon actually parse my input, which uid is it under, what does its own log say. once it can check things it stops guessing, getting qemu to actually boot the thing was its own little hell though, took more tries than i want to admit.

the other thing i learned the hard way: most static findings die on reachability, not on exploit primitives. so i run them in the emulator first and kill the unreachable ones cheap, before spending any time on heap work

on heap vs stack, i think that intuition is desktop shaped. device userland usually has weak or no mitigations, heap uafs are way more tractable there than youd expect

> what percentage of TCP/IP servers are 'multipath'?

no idea, but at least Tailscale and Caddy were opening MPTCP sockets on servers I checked.

My understanding is that an app explicitly needs to open a "multipath" socket. Go 1.24 does that by default, so does Caddy, these would be the big ones.

The good news is, if you emergency patched your Debian for php2shell, you probably got the new kernel on the same apt run. This time the embargo actually held, and the new kernel was out before the CVE came public

Nope. This was just the start.

You would be surprised. A lot of cheap consumer routers are have two or four ARM cores. The bigger issue is that they are typically running a kernel from the stone age (< 6.0.0). Sometimes a still-supported LTS kernel like 5.10 or 5.15, but then they stopped at an old patch level.

Heck, apparently even the new Unifi UCG Fiber is running 5.4.213 (September 2022), but maybe they backport some fixes?

[1] https://community.ui.com/releases/dd0283dc-bf71-4140-ae1d-c1...

My $50 router has two cores.

  root@OpenWrt2:~# lscpu
  Architecture:        mips
  Byte Order:          Little Endian
  CPU(s):              4
  On-line CPU(s) list: 0-3
  Model name:          -
  Model:               MIPS 1004Kc V2.15
  Thread(s) per core:  2
  Core(s) per socket:  2
  Socket(s):           1

Those routers probably have 20 other critical un-patched exploits ...

An entire ecosystem of malware crawling and cohabiting in them.

How does your internet work, if the firewall doesn't accept incoming packets?

OpenWrt doesn't open ports by default so I think the impact is minimal, unless this can breach nftables as well. CGNAT also mitigates this as a side effect.

If you have services open on the IPv4 net however, close them immediately as a precaution.

As much as I hate to link to this site, this particular sub is very good:

https://www.reddit.com/r/openwrt/comments/1xka85h/is_the_ope...

They say 25.12-SNAPSHOT has it fixed

A listener is a piece of software that advertises itself as available to inbound connections. You can do this on a variety of protocols.

Multipath TCP is a neat trick that allows a single TCP connection (TCP = Transport Control Protocol, a stateless protocol for long running connections) to use multiple physical interfaces. You could do something similar before MTCP using bonding, but this was annoying to set up and usually required application level code to efficiently use the bonded connection. MTCP makes this much simpler from an application level point of view and it can use widely diverse underlying transport layers at the same time (for instance, WiFi, Cellular and wired connections).

See https://en.wikipedia.org/wiki/Multipath_TCP

It's an extension to TCP that, similar to QUIC, allows you to use multiple address/port pairs to transmit data over a single logical stream. Both client/initiator and server/listener have to opt into the extension. This might need to be enabled explicitly by the application[1], which Go apparently does for you, or judging from other posts may be enabled by default systemwide, depending on your platform.

AFAIU, a major user of MPTCP is Apple and the iPhone, and the ubiquity of iPhone clients motivated implementation in and deployment on Linux servers.

[1] https://docs.kernel.org/networking/mptcp.html#sockets-api

I had to look it up too since I hadn't heard of it. It's an extension to TCP that allows responses across different NICs. Sort of like Link Aggregation on to a switch, except it can go out dissimilar interfaces, like your wifi connection and your hardwired connection. Looks like you have to opt into it when you set up your socket: https://docs.kernel.org/networking/mptcp.html

You have a Wifi network interface and a wired Ethernet one, multipath is somehow combining the two together.

I went on a security kick early this year, locking down everything as much as I could. Build your systems with the assumption that you WILL get hacked. Limit blast radius. Be prepared.

The next few years will be crazy, but you're right, we'll come out the other side more secure than ever before. Just gotta make it that far!

I wonder if switching to openbsd for my servers soon might be a good idea...

> If they all get found we exit the other side more secure and reliable.

I agree, but as yet we have no idea how much pain we have to pass through to get to the other side.

On the other side we have a Linux networking stack written in Rust.

RCE as root

Yup, was nice to see on my gentoo system. And then this amusing tweet from the grsecurity guy: https://x.com/spendergrsec/status/2116602388471758887

If you use sysctl to disable mptcp, you need to do that again after each reboot.

I've been thinking about this too; it's high time we put the capital-E Engineering into software engineering.

You’re still on slackware? I’ve not thought about it in years! How’re things over there?

Add the below rule onto your machine's /etc/ufw/before.rules to mitigate it.

    # CVE-2026-98432 mitigation: drop TCP packets carrying IPv4 extended options
    -A ufw-before-input -p tcp -m u32 --u32 "0>>24&0xF=6:15" -j DROP

This works for me on multiple servers and home desktops and my hardware linux firewall/router. I did it a couple days ago when this was first announced. The iptables counter for matches haven't gone up at all on my VPS servers that gets lots of traffic. The counter only goes up when I manually trigger it to test. Everything continues to work nominally with these in place.

With only 0.5% of Rust code in the kernel, this does not say much. The binder thing seems to be the only real Rust component so far, and it also mysteriously already had a race condition despite it being impossible to do such mistakes in Rust.

Get rewriting, soldier!

maybe

i’d focus on writing new stuff with rust though, not rewriting old stuff

and time will tell whether it actually reduces bugs or just change the failure modes to something else

also C will always be there in some way or the other, at least in conventions and syntax

It might be bit of an effort to get Fil-C compiling the Linux kernel. As I understand it, it would amount to running garbage collector in the kernel, so some care would probably need to be taken to ensure it doesn't stop things at the wrong time, e.g. interrupts.

Does it support writing kernels?

Wrong. Every kernel from 4.4 onward is affected until the fixed releases (5.10.272, 5.15.223, 6.1.190 and so on).