CVE-2026-74587: sctp: fix use-after-free of cached ASCONF chunk
In the Linux kernel, the following vulnerability has been resolved:
sctp: fix use-after-free of cached ASCONF chunk
addiplastasconf caches the outstanding outbound ASCONF chunk. The normal ASCONF-ACK completion path releases the chunk and clears the pointer.
However, sctpasconfqueueteardown() releases the cached chunk without clearing addiplastasconf. During peer restart handling, sctpsfdodupcooka() queues SCTPCMDPURGEASCONFQUEUE, which invokes sctpasconfqueueteardown() while the association remains alive and leaves the pointer dangling.
A delayed authenticated ASCONF-ACK can then reach sctpsfdoasconfack(), which accesses the stale chunk and passes it to sctpprocessasconfack(), causing a use-after-free and a second release.
Clearing the pointer exposes a race with T4 expiry. Peer restart handling queues the timer stop before the purge, but SCTPCMDTIMERSTOP uses timerdelete(), which does not wait for a callback already running on another CPU. Such a callback can reach sctpsft4timerexpire() after the purge and dereference NULL.
Clear addiplastasconf after releasing the cached chunk, and make sctpsft4timerexpire() consume a stale T4 expiry if no outstanding ASCONF remains.
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
What conditions are required to reach the vulnerable path?
The system must have an SCTP association with an outstanding cached outbound ASCONF chunk. Peer restart handling must purge the ASCONF queue while the association remains alive, followed by a delayed authenticated ASCONF-ACK.
What makes the failure occur after the ASCONF queue is purged?
Queue teardown releases the cached ASCONF chunk but leaves addip_last_asconf pointing to it. A later ASCONF-ACK can use that stale pointer, causing a use-after-free and a second release.
Is the issue limited to the ASCONF acknowledgment path?
No. Clearing the stale pointer also exposes a T4 timer race because timer deletion does not wait for a callback already running on another CPU. The fix makes T4 expiry safely consume a stale expiry when no cached ASCONF chunk remains.