Answer in brief
CVE-2026-68315 records a Unknown severity vulnerability in sctp: validate stream count in sctp_process_strreset_inreq(). The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=7f9d68ac944e24ee5f9ac8d059ca00b1c1d34137 <b255d8cd6cc68045ae9eecbac3b3c14e1f176c9b || >=7f9d68ac944e24ee5f9ac8d059ca00b1c1d34137 <6f0e39d180cd7cced647381b6fa14fd83d261047 || >=7f9d68ac944e24ee5f9ac8d059ca00b1c1d34137 <1a10fe1aa9c01f41b389a31906a77d538637c9d9 || >=7f9d68ac944e24ee5f9ac8d059ca00b1c1d34137 <00ae679cb21a035491fdad8d58dc6d79cc68b675 || >=7f9d68ac944e24ee5f9ac8d059ca00b1c1d34137 <18ae07691d43183d270de8be9dc8e027906015d9 | b255d8cd6cc68045ae9eecbac3b3c14e1f176c9b, 6f0e39d180cd7cced647381b6fa14fd83d261047, 1a10fe1aa9c01f41b389a31906a77d538637c9d9, 00ae679cb21a035491fdad8d58dc6d79cc68b675, 18ae07691d43183d270de8be9dc8e027906015d9 |
| Linux/Linuxgeneric | 4.11 | Not reported |
Published upstream
Aug 10, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 10, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 10, 2026
In 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.
Quoted source text, attributed separately from HOL analysis.
Answer in brief
CVE-2026-68315 records a Unknown severity vulnerability in sctp: validate stream count in sctp_process_strreset_inreq(). The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=7f9d68ac944e24ee5f9ac8d059ca00b1c1d34137 <b255d8cd6cc68045ae9eecbac3b3c14e1f176c9b || >=7f9d68ac944e24ee5f9ac8d059ca00b1c1d34137 <6f0e39d180cd7cced647381b6fa14fd83d261047 || >=7f9d68ac944e24ee5f9ac8d059ca00b1c1d34137 <1a10fe1aa9c01f41b389a31906a77d538637c9d9 || >=7f9d68ac944e24ee5f9ac8d059ca00b1c1d34137 <00ae679cb21a035491fdad8d58dc6d79cc68b675 || >=7f9d68ac944e24ee5f9ac8d059ca00b1c1d34137 <18ae07691d43183d270de8be9dc8e027906015d9 | b255d8cd6cc68045ae9eecbac3b3c14e1f176c9b, 6f0e39d180cd7cced647381b6fa14fd83d261047, 1a10fe1aa9c01f41b389a31906a77d538637c9d9, 00ae679cb21a035491fdad8d58dc6d79cc68b675, 18ae07691d43183d270de8be9dc8e027906015d9 |
| Linux/Linuxgeneric | 4.11 | Not reported |
Published upstream
Aug 10, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 10, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 10, 2026
In 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.
Quoted source text, attributed separately from HOL analysis.