CVE-2026-23321: Linux Kernel Privilege Escalation Flaw

CVE-2026-23321 Overview

CVE-2026-23321 is a kernel vulnerability in the Linux kernel's Multipath TCP (MPTCP) path manager subsystem. The vulnerability exists in the in-kernel MPTCP path manager where endpoints configured with both 'signal' and 'subflow' flags are not properly marked as used under certain conditions. This state tracking inconsistency was discovered through Syzkaller fuzzing and can lead to kernel warnings and potentially unstable system behavior.

The vulnerability occurs when specific MPTCP configuration actions are performed in sequence: setting the subflows limit to 0, creating an MPTCP endpoint with both 'signal' and 'subflow' flags, establishing an MPTCP connection from a different address (which sends an ADD_ADDR but initiates no subflows), and then removing the endpoint. This sequence triggers a warning in the __mark_subflow_endp_available function due to incorrect local_addr_used counter tracking.

Critical Impact
This Linux kernel MPTCP vulnerability can cause kernel warnings and system instability. Systems using MPTCP with signal+subflow endpoint configurations are affected.

Affected Products

Linux kernel with MPTCP support enabled
Systems running kernel versions prior to the security patches
Network environments utilizing Multipath TCP functionality

Discovery Timeline

2026-03-25 - CVE CVE-2026-23321 published to NVD
2026-03-25 - Last updated in NVD database

Technical Details for CVE-2026-23321

Vulnerability Analysis

This vulnerability represents a state tracking flaw in the MPTCP path manager's endpoint management logic. When an MPTCP endpoint is configured with both the 'signal' and 'subflow' flags, the kernel should properly track whether the endpoint has been used for establishing subflows or signaling addresses to peers.

The root cause lies in the mptcp_pm_nl_del_addr_doit function within net/mptcp/pm_kernel.c. When removing an endpoint, the function calls mptcp_nl_remove_subflow_and_signal_addr, which in turn invokes __mark_subflow_endp_available. This function expects the msk->pm.local_addr_used counter to be non-zero before decrementing, but under the specific conditions identified by Syzkaller, this counter remains at 0, triggering a kernel warning.

The exploitation scenario requires local access to configure MPTCP parameters and create network connections. An attacker with sufficient privileges could potentially leverage this state inconsistency to cause system instability or as part of a larger attack chain targeting kernel stability.

Root Cause

The vulnerability stems from improper state tracking in the MPTCP path manager when handling endpoints with dual flags ('signal' and 'subflow'). Specifically, when the subflows limit is set to 0, an endpoint with both flags sends ADD_ADDR announcements (due to the 'signal' flag) but never initiates subflows (due to the limit). This creates a state mismatch where the kernel attempts to decrement a usage counter that was never incremented, resulting in an underflow condition and kernel warning.

The call trace shows the issue originates from:

mptcp_pm_nl_del_addr_doit - Entry point for address deletion
mptcp_nl_remove_subflow_and_signal_addr - Subflow/signal cleanup handler
__mark_subflow_endp_available - Where the warning triggers due to local_addr_used == 0

Attack Vector

The attack requires local access to manipulate kernel networking parameters. The exploitation path involves:

Configuring MPTCP subflow limits via netlink interface
Creating endpoints with specific flag combinations
Establishing MPTCP connections from alternate addresses
Triggering cleanup paths through endpoint removal

The vulnerability can be triggered through the sendmsg system call targeting netlink sockets, as shown in the kernel trace. The attack leverages the generic netlink interface (genl_family_rcv_msg_doit) to invoke the vulnerable MPTCP path manager functions.

Detection Methods for CVE-2026-23321

Indicators of Compromise

Kernel warning messages containing net/mptcp/pm_kernel.c:1071 in system logs
Warnings referencing __mark_subflow_endp_available or mptcp_nl_remove_subflow_and_signal_addr
Unexpected MPTCP path manager behavior when removing endpoints
System instability correlated with MPTCP endpoint configuration changes

Detection Strategies

Monitor kernel logs (dmesg, /var/log/kern.log) for MPTCP-related warnings
Audit netlink socket activity targeting MPTCP configuration
Review MPTCP endpoint configurations for unusual signal+subflow flag combinations
Deploy kernel monitoring to detect anomalous path manager state transitions

Monitoring Recommendations

Enable enhanced kernel logging for the MPTCP subsystem
Configure alerts for kernel warnings containing pm_kernel.c references
Monitor for rapid MPTCP endpoint creation/deletion patterns
Track netlink messages to the MPTCP generic netlink family

How to Mitigate CVE-2026-23321

Immediate Actions Required

Apply kernel security patches from the stable kernel tree
Review MPTCP endpoint configurations and temporarily avoid signal+subflow combinations
Monitor systems for kernel warnings indicating exploitation attempts
Consider disabling MPTCP if not operationally required until patching is complete

Patch Information

The Linux kernel maintainers have released patches addressing this vulnerability across multiple stable branches. The fix ensures that endpoints with both 'signal' and 'subflow' flags are always marked as used, preventing the state tracking inconsistency.

Available patches include:

Organizations should update to patched kernel versions through their distribution's package manager or by compiling updated kernel sources.

Workarounds

Disable MPTCP if not required by setting net.mptcp.enabled=0 via sysctl
Avoid creating MPTCP endpoints with both 'signal' and 'subflow' flags simultaneously
Ensure subflow limits are not set to 0 when using combined endpoint flags
Restrict access to MPTCP netlink configuration interfaces to trusted administrators

bash

# Configuration example
# Disable MPTCP temporarily until patched kernel is deployed
echo 0 | sudo tee /proc/sys/net/mptcp/enabled

# Verify MPTCP is disabled
cat /proc/sys/net/mptcp/enabled

# For persistent configuration, add to /etc/sysctl.conf:
# net.mptcp.enabled = 0