CVE-2026-53183

What it actually does

This is a denial-of-service flaw in the Linux kernel Multipath TCP (MPTCP) receive-window handling. Under certain MPTCP traffic patterns, especially when data is acknowledged on a TCP subflow while it is out of order in the MPTCP sequence space or queued in backlog, the TCP subflow receive window can be artificially inflated. That can allow inbound traffic to exceed the receiver's configured receive buffer limits, increasing memory pressure and potentially degrading or disrupting kernel networking behavior. The issue affects systems with MPTCP enabled and reachable by peers able to establish or influence MPTCP connections.

Why it matters to the business

A vulnerable Linux system using MPTCP could experience network instability, resource exhaustion, degraded application availability, or service interruption. The current exploitation signal is low: EPSS is 0.00479, no public exploit maturity is reported, and it is not listed in CISA KEV or associated with ransomware campaigns. However, because the flaw is in the kernel networking stack, exposed MPTCP-enabled servers or network services should still be prioritized for routine kernel updates and defensive configuration review.

How an attack unfolds

An attacker would need network access to a service or endpoint that accepts or participates in MPTCP connections. The attacker establishes an MPTCP session and generates traffic patterns that cause TCP-level acknowledgements and receive-window accounting to diverge from MPTCP-level sequence handling, such as by driving out-of-order MPTCP data or backlog conditions across subflows. Due to the vulnerable receive-window logic, the subflow receive window may fail to shrink appropriately, causing the receiver to accept more data than its receive buffer should allow. Repeating this across one or more connections can increase kernel memory pressure and may lead to degraded networking performance, connection failures, application disruption, or broader system instability.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for the MPTCP receive-window handling issue. If exact vendor package versions are not yet available, track the relevant distribution kernel advisories and apply the next security or stable kernel update containing the MPTCP fix. Where MPTCP is not required, reduce exposure by disabling MPTCP or preventing untrusted network paths from establishing MPTCP sessions. Also consider limiting access to MPTCP-capable services, applying network-layer rate limits, and monitoring kernel memory pressure until patched.

How to confirm the fix worked

Confirm that systems are running a kernel build that includes the fix for allowing TCP subflow receive windows to shrink correctly under MPTCP. Validate exposure by checking whether MPTCP is enabled and whether any externally reachable services negotiate MPTCP. On Linux, review MPTCP configuration through kernel sysctls and confirm the running kernel package against vendor advisories. After remediation, test that MPTCP functionality still works for intended workloads and monitor for absence of abnormal receive-buffer growth, MPTCP connection instability, kernel memory pressure, or networking-related OOM events during representative traffic.

Typical attack path

1. Identify a Linux host or service with MPTCP enabled and reachable over the network.
2. Establish one or more MPTCP-capable connections to the target service.
3. Manipulate traffic timing, ordering, or subflow behavior so data is acknowledged at the TCP subflow level while remaining out of order or backlogged at the MPTCP layer.
4. Trigger receive-window inflation that allows inbound traffic to exceed intended receive-buffer limits.
5. Sustain or multiply the traffic pattern to increase memory pressure and cause service degradation or denial of service.

How to detect it

There are no known public exploit artifacts, named threat actors, KEV activity, or ransomware associations for this vulnerability. Retrospective detection should focus on behavioral evidence rather than a fixed signature. Review kernel logs, system journals, network telemetry, flow records, and performance metrics for periods of unexplained memory pressure, OOM activity, service instability, or connection failures involving MPTCP-enabled hosts. Useful log sources include journald, dmesg, syslog, kernel ring buffer captures, NetFlow/IPFIX, firewall logs, load balancer logs, packet captures, and host performance telemetry. Look for spikes in MPTCP connections, unusual use of multiple subflows from the same peer, sustained inbound traffic that does not match normal application behavior, receive-buffer growth, TCP memory warnings, backlog pressure, and OOM kills around network-facing services. Because the expected impact is denial of service rather than code execution, absence of malware artifacts does not rule out exploitation.

• mptcp
• MPTCP
• Out of memory: Killed process
• Memory cgroup out of memory
• TCP: out of memory
• page allocation failure
• skb
• soft lockup
• NETDEV WATCHDOG
• /proc/sys/net/mptcp/enabled
• /proc/net/mptcp

What your security team should do

• Inventory Linux systems with MPTCP enabled, prioritizing internet-facing, edge, load-balancing, proxy, VPN, storage, and high-throughput network systems.
• Apply vendor kernel updates as soon as available, even though current exploitation likelihood is low and the issue is not in CISA KEV.
• Disable MPTCP on systems where it is not operationally required.
• Restrict MPTCP-capable services to trusted networks where possible and apply connection or traffic rate limiting for exposed services.
• Add monitoring for MPTCP connection spikes, receive-buffer anomalies, kernel memory pressure, and networking-related out-of-memory events.
• Review recent logs for unexplained service degradation, kernel memory exhaustion, or surges in MPTCP traffic since publication on 2026-06-25.
• Include this vulnerability in kernel patch compliance reporting until all affected systems are updated or MPTCP is disabled.