GHSA-27X2-682M-9QM4
Vulnerability from github – Published: 2026-09-25 12:31 – Updated: 2026-09-25 12:31In 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.
{
"affected": [],
"aliases": [
"CVE-2026-97566"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-25T11:17:07Z",
"severity": null
},
"details": "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\u0027s 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": "GHSA-27x2-682m-9qm4",
"modified": "2026-09-25T12:31:24Z",
"published": "2026-09-25T12:31:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-97566"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2ac7d6e620764f1fc79eb4edd3610a7a661981ca"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/545616b4e7325be3c61fc082538cb06d14f7b1db"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d4a67a880654e1bfe318a31bea0bdbb026a09ade"
}
],
"schema_version": "1.4.0",
"severity": []
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.