sctp: clear control chunk transport if it is being removed
- 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.152, 6.12.104, 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: total
Summary
In the Linux kernel, the following vulnerability has been resolved: sctp: clear control chunk transport if it is being removed sctp_make_heartbeat_ack() caches the destination transport in chunk->transport without taking a reference. When src_out_of_asoc_ok is enabled, the HEARTBEAT ACK may remain queued on control_chunk_list instead of being transmitted immediately. If the peer transport is removed while the chunk is still queued, sctp_assoc_rm_peer() drops the transport and schedules it for RCU freeing, but only clears cached transport pointers in out_chunk_list. The queued control chunk therefore retains a dangling transport pointer. Once an ASCONF_ACK clears the suppression and the queued control chunk is transmitted, SCTP dereferences the stale transport pointer, leading to a use-after-free. Fix this by also clearing chunk->transport for queued control chunks in control_chunk_list when removing the transport.
Timeline
- CVE published
- CISA SSVC assessment
Exploitation: none · Automatable: yes · Technical impact: total
- Record last updated
Affected versions
- Linux Linux
From 8a07eb0a50aebc8c95478d49c28c7f8419a26cef · fixed in dbb3f418a8665ffb0514e1a9520ab6a1c5d4d886; From 8a07eb0a50aebc8c95478d49c28c7f8419a26cef · fixed in fad4766a74220fe579c6fcaa10ba01c23529814f; From 8a07eb0a50aebc8c95478d49c28c7f8419a26cef · fixed in 936658ec41c28c397ef390140e02d4c91ade92f0; From 8a07eb0a50aebc8c95478d49c28c7f8419a26cef · fixed in 8de65194a04d2552cd39b6c67d942d490f22d174; From 8a07eb0a50aebc8c95478d49c28c7f8419a26cef · fixed in 6160e756db81d6cb63e3e2952efcf6c5134be385; From 8a07eb0a50aebc8c95478d49c28c7f8419a26cef · fixed in 18d704bdd809377dfd81a3c2f42426763b5da227; From 8a07eb0a50aebc8c95478d49c28c7f8419a26cef · fixed in 4d6b9cac6df5e0cfef1a66b3edd7aebdb9e4b7e7; From 8a07eb0a50aebc8c95478d49c28c7f8419a26cef · fixed in c9158ceaf27780ef64534ad72f44ffde3f8ccc49
- Linux Linux
3.1
- KernelLinux
From 3.1.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.152; From 6.7.0 · fixed in 6.12.104; From 6.13.0 · fixed in 6.18.45; From 6.19.0 · fixed in 7.1.9
References 8
git.kernel.org
- stable/c/dbb3f418a8665ffb0514e1a9520ab6a1c5d4d886
- stable/c/fad4766a74220fe579c6fcaa10ba01c23529814f
- stable/c/936658ec41c28c397ef390140e02d4c91ade92f0
- stable/c/8de65194a04d2552cd39b6c67d942d490f22d174
- stable/c/6160e756db81d6cb63e3e2952efcf6c5134be385
- stable/c/18d704bdd809377dfd81a3c2f42426763b5da227
- stable/c/4d6b9cac6df5e0cfef1a66b3edd7aebdb9e4b7e7
- stable/c/c9158ceaf27780ef64534ad72f44ffde3f8ccc49