CVE-2026-97566 in Linux
Summary
by MITRE • 09/25/2026
In the Linux kernel, the following vulnerability has been resolved:
mptcp: pm: kernel: drop pending ADD_ADDR when removing ID0
The in-kernel MPTCP path manager can leave a stale ADD_ADDR announcement entry alive when removing the id 0 endpoint. This happens because the id 0 removal path does not tear down pending announcements, unlike the non-zero id path.
When the PM later reselects id 0 after adding another signal endpoint, it finds the stale anno_list entry and hits WARN_ON_ONCE(mptcp_pm_is_kernel()) in mptcp_pm_announced_alloc().
Root cause: asymmetry between removal paths. - Non-zero id path: mptcp_nl_remove_subflow_and_signal_addr() calls mptcp_pm_remove_announced() to clean up. - Id 0 path: mptcp_nl_remove_id_zero_address() skips cleanup entirely.
Fix by making the id 0 path symmetric: call mptcp_pm_announced_remove() and decrement add_addr_signaled before queuing the RM_ADDR.
Subtle detail: signal endpoints are stored in anno_list with port 0, but msk_local carries the connection's local port. In other words, entries linked to ID0 paths should have port == 0. A follow-up patch will ensure that. mptcp_pm_announced_remove() uses use_port=true for comparison. So clear the port before the lookup.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/25/2026
The Linux kernel’s Multipath TCP implementation contains a logic flaw within its path manager component, specifically concerning the handling of endpoint identifiers during removal operations. This vulnerability arises from an asymmetry in how different types of endpoints are managed when they are removed from active connections. The core issue lies in the divergent code paths executed for removing subflow endpoints with non-zero identifiers versus those with identifier zero. When a path manager removes a standard subflow identified by a non-zero ID, it correctly invokes cleanup routines that dismantle pending address announcements associated with that endpoint. However, when an endpoint with identifier zero is removed, the corresponding removal function fails to execute these necessary teardown procedures, leaving stale announcement entries in memory.
This oversight results in the persistence of invalid ADD_ADDR protocol messages within the kernel's internal state structures. These orphaned entries remain active even after their associated network interface or connection context has been dismantled. The presence of this residual data creates a dangerous inconsistency in the path manager’s tracking of announced addresses. Under normal operational conditions, these stale entries might go unnoticed until specific trigger events occur that force the system to re-evaluate its address announcements and endpoint configurations.
The vulnerability manifests most critically when the kernel attempts to reselect identifier zero for use with another signal endpoint after a previous removal operation. During this process, the path manager scans existing announcement lists and encounters the lingering stale entry from the prior ID0 removal. This discovery triggers an internal assertion failure within the mptcp_pm_announced_alloc function, specifically hitting a WARN_ON_ONCE check designed to catch kernel-mode anomalies. While this immediate symptom appears as a warning rather than a crash, it indicates severe state corruption that can lead to unpredictable behavior in subsequent network operations involving Multipath TCP connections.
From a technical perspective, this flaw represents a classic resource management error where cleanup logic is inconsistently applied across similar code paths. The root cause is identified as the omission of calls to mptcp_pm_remove_announced and related decrementing of add_addr_signaled counters in the ID0 removal path. In contrast, non-zero identifier removals properly invoke these functions to ensure all associated protocol state is cleared before queuing remove address signals. This asymmetry violates the principle of consistent resource lifecycle management within the kernel networking stack.
The operational impact extends beyond immediate warning logs. Corrupted internal states in network protocols can lead to connection instability, packet loss, or failure to establish new multipath connections correctly. In high-throughput environments relying on Multipath TCP for redundancy and bandwidth aggregation, such state inconsistencies may degrade performance reliability. Attackers with local access could potentially exploit this inconsistency to cause denial of service conditions by repeatedly triggering endpoint removals that leave stale entries, eventually exhausting kernel memory or causing repeated assertion failures that disrupt network services.
Mitigation strategies primarily involve applying the upstream Linux kernel patches that rectify this asymmetry. The fix ensures symmetry between ID0 and non-zero identifier removal paths by explicitly calling cleanup functions to remove pending announcements before signaling address removals. Additionally, developers must ensure proper handling of port numbers in signal endpoint storage, as entries linked to ID0 paths should maintain a zeroed port field for accurate comparison during lookup operations. System administrators running affected kernel versions should prioritize updating their systems to include these corrections.
This vulnerability aligns with CWE-459, which describes incomplete cleanup upon program exit or error handling, and can be mapped to MITRE ATT&CK techniques related to resource manipulation within operating system components. The lack of proper state synchronization between endpoint removal and announcement management highlights the importance of rigorous code review for network protocol implementations in kernel space. Ensuring that all code paths perform equivalent cleanup operations is critical for maintaining the integrity of complex networking stacks like Multipath TCP.