GHSA-XW85-W2Q2-369X
Vulnerability from github – Published: 2026-08-04 09:31 – Updated: 2026-08-19 18:32In the Linux kernel, the following vulnerability has been resolved:
sctp: don't free the ASCONF's own transport in DEL-IP processing
sctp_process_asconf() caches the transport the ASCONF chunk is processed against in asconf->transport (== chunk->transport, set once in sctp_rcv()). For an ASCONF located through its Address Parameter by __sctp_rcv_asconf_lookup(), that cached transport corresponds to the Address Parameter, which need not be the packet's source address.
sctp_process_asconf_param() rejects a DEL-IP for the packet source address (ADDIP D8, SCTP_ERROR_DEL_SRC_IP), but nothing protects asconf->transport. A single ASCONF can therefore carry, in order:
[Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0]
where L differs from the source. The DEL-IP for L passes the D8 check and calls sctp_assoc_rm_peer() on the transport that asconf->transport still points at, freeing it (RCU-deferred). The following wildcard DEL-IP then reuses the now-dangling asconf->transport in sctp_assoc_set_primary() and sctp_assoc_del_nonprimary_peers(): set_primary() dereferences the freed transport (->ipaddr, ->state) and plants the dangling pointer into asoc->peer.primary_path / active_path, and del_nonprimary_peers(), keeping only the pointer that is no longer on the list, removes every real transport, leaving the association with a transport_count of 0 and primary_path/active_path pointing at freed memory.
Reject a DEL-IP that targets the transport the ASCONF is being processed against, mirroring the existing source-address guard, so the wildcard branch can never reuse a freed transport.
{
"affected": [],
"aliases": [
"CVE-2026-64564"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-04T07:16:31Z",
"severity": "CRITICAL"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsctp: don\u0027t free the ASCONF\u0027s own transport in DEL-IP processing\n\nsctp_process_asconf() caches the transport the ASCONF chunk is processed\nagainst in asconf-\u003etransport (== chunk-\u003etransport, set once in sctp_rcv()).\nFor an ASCONF located through its Address Parameter by\n__sctp_rcv_asconf_lookup(), that cached transport corresponds to the\nAddress Parameter, which need not be the packet\u0027s source address.\n\nsctp_process_asconf_param() rejects a DEL-IP for the packet source address\n(ADDIP D8, SCTP_ERROR_DEL_SRC_IP), but nothing protects asconf-\u003etransport.\nA single ASCONF can therefore carry, in order:\n\n [Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0]\n\nwhere L differs from the source. The DEL-IP for L passes the D8 check and\ncalls sctp_assoc_rm_peer() on the transport that asconf-\u003etransport still\npoints at, freeing it (RCU-deferred). The following wildcard DEL-IP then\nreuses the now-dangling asconf-\u003etransport in sctp_assoc_set_primary() and\nsctp_assoc_del_nonprimary_peers(): set_primary() dereferences the freed\ntransport (-\u003eipaddr, -\u003estate) and plants the dangling pointer into\nasoc-\u003epeer.primary_path / active_path, and del_nonprimary_peers(), keeping\nonly the pointer that is no longer on the list, removes every real\ntransport, leaving the association with a transport_count of 0 and\nprimary_path/active_path pointing at freed memory.\n\nReject a DEL-IP that targets the transport the ASCONF is being processed\nagainst, mirroring the existing source-address guard, so the wildcard\nbranch can never reuse a freed transport.",
"id": "GHSA-xw85-w2q2-369x",
"modified": "2026-08-19T18:32:03Z",
"published": "2026-08-04T09:31:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64564"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2b324ba3494ae958cba16a453e3e71489b4de7fc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/74e8f3e7114f0e26d1b2c4c048044db9fcc27603"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/85aca407c560aba81b5ce9d3d6cf94c74077d19b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9b2854f86f0b56e9027d68e7a3fc909d1a9b566f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a63afa1f9b12d5293cbe0b77fd45dc0632533a13"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a9ce31be4cb1a5dd82b3e0a1d0c3e7cbdcd31293"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d136b29bf91dd8e3161281b87de597b7311d9462"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fedeb4468987bcaff85fe3061de5ae052d414740"
},
{
"type": "WEB",
"url": "https://matrix.tencent.com/en/2026/08/06/sctphantom-CVE-2026-64564"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/08/06/13"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/08/06/3"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/08/06/4"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/08/07/1"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/08/07/2"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/08/07/8"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
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.