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.
zetlyn/cve-nvd vulnerability cve CVE-2026-97566 known 2026-09-25
https://nvd.nist.gov/vuln/detail/CVE-2026-97566
Properties
| product | Linuxreceipt
What the source handed over{
"cve": {
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"net/mptcp/pm_kernel.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "d4a67a880654e1bfe318a31bea0bdbb026a09ade",
"status": "affected",
"version": "740d798e8767d8a449902b1a1bbc70facfce19b5",
"versionType": "git"
},
{
"lessThan": "545616b4e7325be3c61fc082538cb06d14f7b1db",
"status": "affected",
"version": "740d798e8767d8a449902b1a1bbc70facfce19b5",
"versionType": "git"
},
{
"lessThan": "2ac7d6e620764f1fc79eb4edd3610a7a661981ca",
"status": "affected",
"version": "740d798e8767d8a449902b1a1bbc70facfce19b5",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"net/mptcp/pm_kernel.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "5.13"
},
{
"lessThan": "5.13",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.18.*",
"status": "unaffected",
"version": "6.18.53",
"versionType": "semver"
},
{
"lessThanOrEqual": "7.2.*",
"status": "unaffected",
"version": "7.2.7",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "7.3-rc3",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: pm: kernel: drop pending ADD_ADDR when removing ID0\n\nThe in-kernel MPTCP path manager can leave a stale ADD_ADDR announcement\nentry alive when removing the id 0 endpoint. This happens because the id 0\nremoval path does not tear down pending announcements, unlike the non-zero\nid path.\n\nWhen the PM later reselects id 0 after adding another signal endpoint, it\nfinds the stale anno_list entry and hits WARN_ON_ONCE(mptcp_pm_is_kernel())\nin mptcp_pm_announced_alloc().\n\nRoot cause: asymmetry between removal paths.\n- Non-zero id path: mptcp_nl_remove_subflow_and_signal_addr() calls\n mptcp_pm_remove_announced() to clean up.\n- Id 0 path: mptcp_nl_remove_id_zero_address() skips cleanup entirely.\n\nFix by making the id 0 path symmetric: call mptcp_pm_announced_remove()\nand decrement add_addr_signaled before queuing the RM_ADDR.\n\nSubtle detail: signal endpoints are stored in anno_list with port 0, but\nmsk_local carries the connection's local port. In other words, entries\nlinked to ID0 paths should have port == 0. A follow-up patch will ensure\nthat. mptcp_pm_announced_remove() uses use_port=true for comparison. So\nclear the port before the lookup."
}
],
"id": "CVE-2026-97566",
"lastModified": "2026-09-25T11:17:07.233",
"metrics": {},
"published": "2026-09-25T11:17:07.233",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/2ac7d6e620764f1fc79eb4edd3610a7a661981ca"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/545616b4e7325be3c61fc082538cb06d14f7b1db"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/d4a67a880654e1bfe318a31bea0bdbb026a09ade"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Received"
}
} | ||||
|---|---|---|---|---|---|
| status | Receivedreceipt
What the source handed over{
"cve": {
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"net/mptcp/pm_kernel.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "d4a67a880654e1bfe318a31bea0bdbb026a09ade",
"status": "affected",
"version": "740d798e8767d8a449902b1a1bbc70facfce19b5",
"versionType": "git"
},
{
"lessThan": "545616b4e7325be3c61fc082538cb06d14f7b1db",
"status": "affected",
"version": "740d798e8767d8a449902b1a1bbc70facfce19b5",
"versionType": "git"
},
{
"lessThan": "2ac7d6e620764f1fc79eb4edd3610a7a661981ca",
"status": "affected",
"version": "740d798e8767d8a449902b1a1bbc70facfce19b5",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"net/mptcp/pm_kernel.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "5.13"
},
{
"lessThan": "5.13",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.18.*",
"status": "unaffected",
"version": "6.18.53",
"versionType": "semver"
},
{
"lessThanOrEqual": "7.2.*",
"status": "unaffected",
"version": "7.2.7",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "7.3-rc3",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: pm: kernel: drop pending ADD_ADDR when removing ID0\n\nThe in-kernel MPTCP path manager can leave a stale ADD_ADDR announcement\nentry alive when removing the id 0 endpoint. This happens because the id 0\nremoval path does not tear down pending announcements, unlike the non-zero\nid path.\n\nWhen the PM later reselects id 0 after adding another signal endpoint, it\nfinds the stale anno_list entry and hits WARN_ON_ONCE(mptcp_pm_is_kernel())\nin mptcp_pm_announced_alloc().\n\nRoot cause: asymmetry between removal paths.\n- Non-zero id path: mptcp_nl_remove_subflow_and_signal_addr() calls\n mptcp_pm_remove_announced() to clean up.\n- Id 0 path: mptcp_nl_remove_id_zero_address() skips cleanup entirely.\n\nFix by making the id 0 path symmetric: call mptcp_pm_announced_remove()\nand decrement add_addr_signaled before queuing the RM_ADDR.\n\nSubtle detail: signal endpoints are stored in anno_list with port 0, but\nmsk_local carries the connection's local port. In other words, entries\nlinked to ID0 paths should have port == 0. A follow-up patch will ensure\nthat. mptcp_pm_announced_remove() uses use_port=true for comparison. So\nclear the port before the lookup."
}
],
"id": "CVE-2026-97566",
"lastModified": "2026-09-25T11:17:07.233",
"metrics": {},
"published": "2026-09-25T11:17:07.233",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/2ac7d6e620764f1fc79eb4edd3610a7a661981ca"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/545616b4e7325be3c61fc082538cb06d14f7b1db"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/d4a67a880654e1bfe318a31bea0bdbb026a09ade"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Received"
}
} | ||||
| vendor | Linuxreceipt
What the source handed over{
"cve": {
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"net/mptcp/pm_kernel.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "d4a67a880654e1bfe318a31bea0bdbb026a09ade",
"status": "affected",
"version": "740d798e8767d8a449902b1a1bbc70facfce19b5",
"versionType": "git"
},
{
"lessThan": "545616b4e7325be3c61fc082538cb06d14f7b1db",
"status": "affected",
"version": "740d798e8767d8a449902b1a1bbc70facfce19b5",
"versionType": "git"
},
{
"lessThan": "2ac7d6e620764f1fc79eb4edd3610a7a661981ca",
"status": "affected",
"version": "740d798e8767d8a449902b1a1bbc70facfce19b5",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"net/mptcp/pm_kernel.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "5.13"
},
{
"lessThan": "5.13",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.18.*",
"status": "unaffected",
"version": "6.18.53",
"versionType": "semver"
},
{
"lessThanOrEqual": "7.2.*",
"status": "unaffected",
"version": "7.2.7",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "7.3-rc3",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: pm: kernel: drop pending ADD_ADDR when removing ID0\n\nThe in-kernel MPTCP path manager can leave a stale ADD_ADDR announcement\nentry alive when removing the id 0 endpoint. This happens because the id 0\nremoval path does not tear down pending announcements, unlike the non-zero\nid path.\n\nWhen the PM later reselects id 0 after adding another signal endpoint, it\nfinds the stale anno_list entry and hits WARN_ON_ONCE(mptcp_pm_is_kernel())\nin mptcp_pm_announced_alloc().\n\nRoot cause: asymmetry between removal paths.\n- Non-zero id path: mptcp_nl_remove_subflow_and_signal_addr() calls\n mptcp_pm_remove_announced() to clean up.\n- Id 0 path: mptcp_nl_remove_id_zero_address() skips cleanup entirely.\n\nFix by making the id 0 path symmetric: call mptcp_pm_announced_remove()\nand decrement add_addr_signaled before queuing the RM_ADDR.\n\nSubtle detail: signal endpoints are stored in anno_list with port 0, but\nmsk_local carries the connection's local port. In other words, entries\nlinked to ID0 paths should have port == 0. A follow-up patch will ensure\nthat. mptcp_pm_announced_remove() uses use_port=true for comparison. So\nclear the port before the lookup."
}
],
"id": "CVE-2026-97566",
"lastModified": "2026-09-25T11:17:07.233",
"metrics": {},
"published": "2026-09-25T11:17:07.233",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/2ac7d6e620764f1fc79eb4edd3610a7a661981ca"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/545616b4e7325be3c61fc082538cb06d14f7b1db"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/d4a67a880654e1bfe318a31bea0bdbb026a09ade"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Received"
}
} |
Text
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.