sctp: validate stream count in sctp_process_strreset_inreq()
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 5.10.265, 5.15.216, 6.1.183, 6.6.148, 6.12.101, and 2 more
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: none
- Automatable: yes
- Technical impact: partial
Summary
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.
Timeline
- CVE published
- CISA SSVC assessment
Exploitation: none · Automatable: yes · Technical impact: partial
- Record last updated
Affected versions
- Linux Linux
From 7f9d68ac944e24ee5f9ac8d059ca00b1c1d34137 · fixed in 61327d8e7cfb0259d527be17202630f556213249; From 7f9d68ac944e24ee5f9ac8d059ca00b1c1d34137 · fixed in 7cf7439948e3bf639119119922c88ec190874ca3; From 7f9d68ac944e24ee5f9ac8d059ca00b1c1d34137 · fixed in 60c47dea5d320d2fc706e9aad1db38a04df0a056; From 7f9d68ac944e24ee5f9ac8d059ca00b1c1d34137 · fixed in b255d8cd6cc68045ae9eecbac3b3c14e1f176c9b; From 7f9d68ac944e24ee5f9ac8d059ca00b1c1d34137 · fixed in 6f0e39d180cd7cced647381b6fa14fd83d261047; From 7f9d68ac944e24ee5f9ac8d059ca00b1c1d34137 · fixed in 1a10fe1aa9c01f41b389a31906a77d538637c9d9; From 7f9d68ac944e24ee5f9ac8d059ca00b1c1d34137 · fixed in 00ae679cb21a035491fdad8d58dc6d79cc68b675; From 7f9d68ac944e24ee5f9ac8d059ca00b1c1d34137 · fixed in 18ae07691d43183d270de8be9dc8e027906015d9
- Linux Linux
4.11
- KernelLinux
From 4.11.0 · fixed in 5.10.265; From 5.11.0 · fixed in 5.15.216; From 5.16.0 · fixed in 6.1.183; From 6.2.0 · fixed in 6.6.148; From 6.7.0 · fixed in 6.12.101; From 6.13.0 · fixed in 6.18.42; From 6.19.0 · fixed in 7.1.6
References 8
git.kernel.org
- stable/c/61327d8e7cfb0259d527be17202630f556213249
- stable/c/7cf7439948e3bf639119119922c88ec190874ca3
- stable/c/60c47dea5d320d2fc706e9aad1db38a04df0a056
- stable/c/b255d8cd6cc68045ae9eecbac3b3c14e1f176c9b
- stable/c/6f0e39d180cd7cced647381b6fa14fd83d261047
- stable/c/1a10fe1aa9c01f41b389a31906a77d538637c9d9
- stable/c/00ae679cb21a035491fdad8d58dc6d79cc68b675
- stable/c/18ae07691d43183d270de8be9dc8e027906015d9