CVE-2026-97566: mptcp: pm: kernel: drop pending ADD_ADDR when removing ID0
In the Linux kernel, the following vulnerability has been resolved:
mptcp: pm: kernel: drop pending ADDADDR when removing ID0
The in-kernel MPTCP path manager can leave a stale ADDADDR 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 annolist entry and hits WARNONONCE(mptcppmiskernel()) in mptcppmannouncedalloc().
Root cause: asymmetry between removal paths. - Non-zero id path: mptcpnlremovesubflowandsignaladdr() calls mptcppmremoveannounced() to clean up. - Id 0 path: mptcpnlremoveidzeroaddress() skips cleanup entirely.
Fix by making the id 0 path symmetric: call mptcppmannouncedremove() and decrement addaddrsignaled before queuing the RMADDR.
Subtle detail: signal endpoints are stored in annolist with port 0, but msklocal 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. mptcppmannouncedremove() uses useport=true for comparison. So clear the port before the lookup.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Make the MPTCP ID 0 endpoint removal path symmetric with the non-zero path by calling mptcp_pm_announced_remove() to clean up pending ADD_ADDR announcements; clear the port before lookup and decrement add_addr_signaled before queuing RM_ADDR.
Event History
Frequently Asked Questions
Which deployments are exposed to the warning condition?
Systems using the in-kernel MPTCP path manager can reach it when the ID 0 endpoint is removed and another signal endpoint is subsequently added, causing ID 0 to be selected again.
How can an administrator tell that this condition has occurred?
The kernel can trigger WARN_ON_ONCE(mptcp_pm_is_kernel()) in mptcp_pm_announced_alloc() when it encounters the stale announcement entry.
What does the fix need to do?
The ID 0 removal path must remove pending announcements and decrement add_addr_signaled before queuing RM_ADDR, matching the cleanup performed for non-zero endpoint IDs.