GHSA-XM4M-QJ4Q-FPC2
Vulnerability from github – Published: 2026-08-10 15:33 – Updated: 2026-08-19 18:32In the Linux kernel, the following vulnerability has been resolved:
sctp: validate stream count in sctp_process_strreset_inreq()
When processing a RESET_IN_REQUEST from a peer, sctp_process_strreset_inreq() derives the stream count from the parameter length but does not check whether the resulting RESET_OUT_REQUEST would exceed SCTP_MAX_CHUNK_LEN.
The OUT request header (sctp_strreset_outreq, 16 bytes) is 8 bytes larger than the IN request header (sctp_strreset_inreq, 8 bytes). Generally, the IP payload is bounded to 65535 bytes, so the stream list cannot be large enough to trigger the overflow. However, on interfaces with MTU > 65535 (e.g., loopback with IPv6 jumbograms), a stream list that fits within the incoming IN parameter can cause a __u16 overflow in sctp_make_strreset_req() when computing the OUT request size, leading to an undersized skb allocation and a kernel BUG:
net/core/skbuff.c:207 skb_panic net/core/skbuff.c:2625 skb_put net/sctp/sm_make_chunk.c:1535 sctp_addto_chunk net/sctp/sm_make_chunk.c:3695 sctp_make_strreset_req net/sctp/stream.c:655 sctp_process_strreset_inreq
The local setsockopt path validates the generated reset request size. However, for an incoming-only reset, it accounts for the smaller IN request even though the peer must generate an OUT request with the same stream list. Such a request cannot be completed successfully by the peer.
Reject peer IN requests whose corresponding OUT request would exceed SCTP_MAX_CHUNK_LEN. Also tighten the local check so it does not send an IN request that would require an oversized OUT request from the peer.
{
"affected": [],
"aliases": [
"CVE-2026-68315"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-10T13:20:21Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsctp: validate stream count in sctp_process_strreset_inreq()\n\nWhen processing a RESET_IN_REQUEST from a peer,\nsctp_process_strreset_inreq() derives the stream count from the\nparameter length but does not check whether the resulting\nRESET_OUT_REQUEST would exceed SCTP_MAX_CHUNK_LEN.\n\nThe OUT request header (sctp_strreset_outreq, 16 bytes) is 8 bytes\nlarger than the IN request header (sctp_strreset_inreq, 8 bytes).\nGenerally, the IP payload is bounded to 65535 bytes, so the stream\nlist cannot be large enough to trigger the overflow. However, on\ninterfaces with MTU \u003e 65535 (e.g., loopback with IPv6 jumbograms), a\nstream list that fits within the incoming IN parameter can cause a\n__u16 overflow in sctp_make_strreset_req() when computing the OUT\nrequest size, leading to an undersized skb allocation and a kernel\nBUG:\n\n net/core/skbuff.c:207 skb_panic\n net/core/skbuff.c:2625 skb_put\n net/sctp/sm_make_chunk.c:1535 sctp_addto_chunk\n net/sctp/sm_make_chunk.c:3695 sctp_make_strreset_req\n net/sctp/stream.c:655 sctp_process_strreset_inreq\n\nThe local setsockopt path validates the generated reset request size.\nHowever, for an incoming-only reset, it accounts for the smaller IN\nrequest even though the peer must generate an OUT request with the same\nstream list. Such a request cannot be completed successfully by the\npeer.\n\nReject peer IN requests whose corresponding OUT request would exceed\nSCTP_MAX_CHUNK_LEN. Also tighten the local check so it does not send an\nIN request that would require an oversized OUT request from the peer.",
"id": "GHSA-xm4m-qj4q-fpc2",
"modified": "2026-08-19T18:32:14Z",
"published": "2026-08-10T15:33:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-68315"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/00ae679cb21a035491fdad8d58dc6d79cc68b675"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/18ae07691d43183d270de8be9dc8e027906015d9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1a10fe1aa9c01f41b389a31906a77d538637c9d9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/60c47dea5d320d2fc706e9aad1db38a04df0a056"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/61327d8e7cfb0259d527be17202630f556213249"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6f0e39d180cd7cced647381b6fa14fd83d261047"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7cf7439948e3bf639119119922c88ec190874ca3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b255d8cd6cc68045ae9eecbac3b3c14e1f176c9b"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/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.