CVE-2026-74688: sctp: clear control chunk transport if it is being removed
In the Linux kernel, the following vulnerability has been resolved:
sctp: clear control chunk transport if it is being removed
sctpmakeheartbeatack() caches the destination transport in chunk->transport without taking a reference. When srcoutofasocok is enabled, the HEARTBEAT ACK may remain queued on controlchunklist instead of being transmitted immediately.
If the peer transport is removed while the chunk is still queued, sctpassocrmpeer() drops the transport and schedules it for RCU freeing, but only clears cached transport pointers in outchunklist. The queued control chunk therefore retains a dangling transport pointer.
Once an ASCONFACK 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 controlchunklist when removing the transport.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 6.6.152.1-1
Event History
Frequently Asked Questions
Which configurations are exposed to this condition?
The vulnerable path requires SCTP with src_out_of_asoc_ok enabled. The provided information does not state whether that setting is enabled by default.
What sequence is needed to trigger the use-after-free?
A HEARTBEAT ACK must remain queued on the control chunk list while its peer transport is removed. An ASCONF_ACK must later clear the suppression and cause the queued control chunk to be sent, at which point the stale transport pointer can be dereferenced.
How can I verify that a kernel contains the fix?
No affected or fixed kernel versions are provided. Verify that the SCTP peer-transport removal path clears chunk->transport for queued entries in control_chunk_list, in addition to entries in out_chunk_list.