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

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

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