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.
- Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.113-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 7.2.7-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.113-1~deb12u1 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.1.191 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.6.160 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.12.112 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.18.53 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 7.2.7 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.115-2Fixed in 7.2.12-1Fixed in 7.2.15-1 - Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Patch mptcp: pm: kernel: drop pending ADD_ADDR when removing ID0
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.