Some notes I've got about this:
- MPTCP is not a requirement, it is a generic use-after-free.
- Exploitability over the internet is unlikely, most ISP routers drop packets with IP options fields.
- At least according to Red Hat, dropping packets with IP options yourself helps, but is not a full mitigation.
- Successful exploit requires multiple CPU cores to process packets, so systems with just a single core or packet processing pinned to a single core are not affected.
> 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+%.
MPTCP uses TCP options fields, the vulnerability is in IP options.
There are two types of multipath TCP and they are not at all the same.
What Apple does is, for example, being able to have a connection over WiFi and 5G simultaneously, with different IPs and routes.
The more traditional server side multipath is that you have a network card with 4 ports (eg 4x 25gbit) and connect them to a router, and make those 4 physical ports (paths) behave like a single interface. This helps either load balancing or redundancy.
The latter is what this vulnerability is about.
Sorry but that's plain wrong.
Neither has layer 2 LAG nor has layer 3 ECMP anything to-do with layer 4 MPTCP.
What's vulnerable is MPTCP.
That’s typically done with thinks like lacp, not multipath
Dropping packets with IP options from XDP should be a more complete mitigation (also more performant).
https://en.wikipedia.org/wiki/Express_Data_Path for anyone else wondering what that is
tl;dr: eBPF programs that run hot off the DMA buffers, before skbufs are created, that can XDP_DROP packets.
In some cases on the NIC itself! (i'm sure you know this)
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.
Eh, this is why networks ossify and we can’t have nice things like a maintained connection when switching from home wifi to 5G. MPTCP is important, eg Siri uses it I believe?
MPTCP doesn't require IP options. Confused at what you are trying to say.
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...
What does the vuln have to do with IP option field then?
The use-after-free occurs within ip_options_build (net/ipv4/ip_options.c) which CPU #2 processing the retransmitted SYN packet uses to read/copy options out of the unallocated/reallocated memory that CPU #1 had already freed up. Remember that the options header is variable length too so CPU #2 is seemingly under-reading/over-reading this variable length options header by some fairly random amount between 1-256 bytes depending on what data has been written to the reallocated memory.[1]
The undocumented part (per LKML discussions at least) is what happens next in the attack. Seemingly CPU #2 or CPU #3[2] comes along later to process the random jibberish options header and rarely (in Anthropic's case it took 48min locally) that random jibberish will be returned to the attacker (e.g. copy jibberish options header to a response packet?) and it'll expose a return pointer to a fixed kernel function. The attacker then crafts a SYN packet and retransmits it with an options header that places a return pointer in the right place, and hopes for another race to occur where CPU #3[2] executes a callback to an attacker-controlled pointer stored within the options header data. Anthrophic's case said it took 5min for this stage of the attack to work locally.
Someone will probably write this all up at some point and it'll be quite a long and detailed read of how the 48min and 5min stages of the attack work and perhaps this is where MPTCP code paths are involved due to the way they process the TCP options header data.
[1] https://en.wikipedia.org/wiki/Internet_Protocol_Options
[1] Author of the kernel patch suggests that CPU #3 (three way race) is needed per https://lore.kernel.org/netdev/CAL4WiiroQ8XyDzUnmuy5FmJ4SWfZ...
Do
sudo tcpdump --immediate-mode -p -nn -i eth0 -vvv -c 1 'ip and (ip[0] & 0x0f > 5)'
to see if you even get them from upstream.
You can even ping it from outside with these packets in the meantime
ping -R -c 3 $IP
One can also monitor for it in nftables. This is from my raw table:
Once confident nothing legit would be blocked by dropping the packets one can change "log prefix "CVE-2026-98432: " level debug" to "drop" if on an unpatched kernel.$ADDR4 in my case in my internet facing interface.
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...