A serious vulnerability was discovered and recently patched in the Linux kernel's Multipath TCP (MPTCP) subsystem. CVE-2024-53122 involves a race condition during subflow creation, which could lead to a division by zero error under certain circumstances. This post breaks down — in a straightforward way — how this vulnerability works and how it could be exploited. We'll also look at the patch, sample code snippets, and references for further reading.

Quick Introduction to MPTCP

Multipath TCP is an extension of regular TCP, allowing a single connection to use multiple paths — for example, on a phone that has both WiFi and cellular data available. The kernel's MPTCP module manages multiple "subflows" that are bound into one logical connection.

What’s the Problem? (The Vulnerability)

When an application receives data using recvmsg() on an MPTCP connection, the kernel calls a cleanup function called tcp_cleanup_rbuf() on all subflows currently known.

However, due to a race condition, it was possible for the in-kernel path manager to add a new subflow to the list _before_ its three-way handshake (3whs) finished — that is, while the new subflow was still not "ready" for data. If recvmsg() was called at this exact moment, tcp_cleanup_rbuf() would be called on this half-baked subflow, potentially resulting in a divide by zero error — which could crash the kernel (Denial of Service).

In simpler words:
A program could crash your system by calling recvmsg() at the wrong time, while MPTCP is busy setting up a new subflow.

Let's see what went wrong

Before Patch:
The kernel looped over all subflows, calling tcp_cleanup_rbuf() on each without checking their true state:

// Vulnerable: No state check!
list_for_each_entry(msk, &mpcb->conn_list, node) {
    tcp_cleanup_rbuf(subflow);
}

After Patch:

The fix is simple and direct: check the state before cleaning up the receive buffer

list_for_each_entry(msk, &mpcb->conn_list, node) {
    if (subflow->sk_state == TCP_ESTABLISHED) {
        tcp_cleanup_rbuf(subflow);
    }
}

That's it — with one extra condition, the function only acts on subflows that are fully established and cannot hit divide-by-zero.

Rapidly call recvmsg() in a loop,

- While multiple subflows are being created (for example, if the network is available on multiple interfaces).

An attacker with the ability to open and read from MPTCP sockets (not usually privileged) could potentially cause a Denial of Service (kernel panic), since Linux kernel code runs with full privileges.

Proof of Concept (PoC) Pseudocode

# pseudocode
import socket
import threading

def race_receive(sock):
    while True:
        try:
            sock.recv(4096)
        except:
            break

# setup an MPTCP socket
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM, socket.IPPROTO_MPTCP)
sock.connect((target_host, target_port))

# in another thread, try to manipulate the network so kernel creates new subflows...
# (e.g., by bringing interfaces up/down)

# meanwhile, hammer recv in parallel:
t = threading.Thread(target=race_receive, args=(sock,))
t.start()

While the above code is illustrative and not copy-paste exploit code, a determined attacker could expand on this to generate precise timing and conditions.

Patch:

- Fix commit in kernel.org

Affected versions:

- Linux kernels with MPTCP support prior to late May 2024 (exact versions: check your distribution’s bulletin)

References:

- Upstream patch discussion (lore.kernel.org)
- NVD Entry for CVE-2024-53122 *(when published)*

How to Protect Yourself

- Update your kernel: Make sure your Linux system is on a release with the patch applied. Most distributions shipped with MPTCP enable it, so update ASAP.
- Minimize attack surface: If MPTCP isn't necessary, consider disabling it via kernel config or sysctl.

Final Thoughts

CVE-2024-53122 shows why kernel race conditions are dangerous, especially in less-exercised code paths like advanced TCP extensions. It’s a good example of how subtle code mistakes — like not checking a state before calling a function — can have system-wide impacts.

Stay safe, and keep your systems patched!

Further Reading:
- MPTCP kernel docs
- Linux MPTCP repo


*This post is original and written for this request. For citing, please refer to official Linux and security advisories for your distribution.*

Timeline

Published on: 12/02/2024 14:15:13 UTC
Last modified on: 12/19/2024 09:39:46 UTC