Multipath TCP Was Already in Your Kernel: Detection Before You Patch

A vulnerability in Linux's Multipath TCP implementation is a useful reminder that RFC 8684 has been sitting in mainline kernels for years, mostly unmonitored. The patch is the easy part — the harder question is whether anything in your estate would notice MPTCP traffic at all.

The protocol features that hurt you are rarely the ones you chose. They arrive in a kernel release, sit dormant because almost no application asks for them, and then surface years later as a CVE against code nobody in your organisation has ever consciously run. Multipath TCP is a textbook case: standardised as RFC 8684 in 2020, merged into mainline Linux well before most estates refreshed their base images, and now the subject of a vulnerability in the Linux implementation.

Patch it, obviously. But the more interesting exposure here isn't the bug — it's that MPTCP breaks a few assumptions your detection stack quietly depends on, and most teams have never checked whether their tooling copes.

What MPTCP actually changes

Ordinary TCP gives you a connection pinned to one four-tuple. One source address, one destination address, two ports, and a single stream of bytes that any sensor sitting in the path can reassemble. Everything from your IDS rules to your flow records to your firewall state table is built on that assumption.

MPTCP decouples the application-level connection from the network path. A single logical connection can carry multiple TCP subflows, each with its own four-tuple, each potentially traversing a different interface or route, with the data reassembled at the endpoints. The negotiation happens in TCP option kind 30 — MP_CAPABLE on the initial handshake, MP_JOIN with a token and HMAC to attach further subflows to an existing session. If an on-path device strips the option, the connection falls back to plain TCP and nothing visibly breaks. That graceful fallback is why MPTCP has been deployable on the public internet at all, and also why it has gone largely unnoticed.

Why your sensors probably cannot see it

Split a stream across two subflows on two paths and a sensor watching one of those paths sees a fragment of the conversation that reassembles into nothing meaningful. Content inspection, signature matching, DLP keyword rules — all of it degrades to noise. This isn't a theoretical evasion technique; it's the documented behaviour of the protocol working as designed, and it has been discussed in the research community since the MPTCP v0 days.

The practical questions for anyone running network detection are narrow and answerable. Does your NDR or IDS parse TCP option 30 and correlate subflows by token? Does it at least alert on the presence of MPTCP where you don't expect it? Does your flow collector record anything that would let you join the subflows after the fact? For most products the honest answer is some version of "partially, if you enable it" — and the only way to find out is to ask the vendor directly and then test it, rather than trusting a datasheet.

The exposure question comes before the patch question

Linux will not generally use MPTCP unless something asks for it. Applications have to open a socket with the MPTCP protocol family, or be wrapped by a shim that rewrites the socket call at runtime. That means the set of hosts genuinely speaking MPTCP in a typical enterprise estate is small — and the set with the code path reachable from the network is governed by the kernel sysctl and by whatever is listening.

So the first job is inventory, not remediation. Check net.mptcp.enabled across your Linux fleet and record the answer per image and per distribution, because defaults vary by kernel version and by vendor. Check which, if any, services are bound to MPTCP sockets. Then widen the question to the Linux you don't think of as Linux: load balancers, firewalls, hypervisor management planes, storage controllers, network appliances and container host images. Those are the places where a kernel-level protocol bug lands with a vendor-dependent fix timeline you don't control.

There is also legitimate MPTCP out there. Apple has used it for some first-party services for years, and the mobile world has standardised on it for steering traffic between cellular and Wi-Fi. If you run anything that touches those ecosystems, "block MPTCP everywhere" is not a free decision.

Detection worth building

MPTCP is cheap to spot if you are looking for it, because the option is in the SYN. A rule that flags TCP option kind 30 on connections crossing a boundary where you've never expected multipath behaviour gives you a high-signal, low-volume alert. Treat it the way you'd treat an unexpected tunnelling protocol: not inherently malicious, but worth a question.

A reasonable order of work:

Take the CVE identifier and the fixed kernel versions from your distribution's security advisory rather than from any secondhand summary, and map them against your actual running kernels — not your package manifests.
Record net.mptcp.enabled per host class, and disable it in base images where no application needs it.
Ask your IDS/NDR vendor, in writing, how their engine handles subflow reassembly and what happens to signature coverage when a stream is split.
Add an alert for TCP option kind 30 at your egress and east-west monitoring points, baseline it for a fortnight, then tune.
Raise the same question with appliance vendors whose products are Linux underneath, and get a fixed-version commitment.

[AUTHOR: add a real example from your own work here, if you have one — e.g. a time an unused kernel feature turned out to be enabled estate-wide.]

The familiar bottleneck

Kernel CVEs expose the same weakness every time: the fix exists within days, and the estate absorbs it over months, because patching a kernel means a reboot and a reboot means a change window. Live patching helps for some classes of fix and some subscriptions, and it is worth knowing in advance which of your hosts are eligible rather than discovering it mid-incident. For appliances, you are waiting on the vendor regardless, which is exactly why the sysctl and the firewall policy matter — they are the controls you can actually turn today.

My view is that the lasting value of an item like this isn't the patch. It's the prompt to go and check one specific assumption — that every TCP connection crossing your perimeter reassembles into a single inspectable stream — and to find out, concretely, whether your tooling still earns the trust you've placed in it.

Source: Multipath TCP: Use and Detection (SANS Internet Storm Center)