Linux kernel (Linux) SCTP TOCTOU race can cause use-after-free

In the Linux kernel, the following vulnerability has been resolved: sctp: fix a TOCTOU race in SCTP_CMD_TIMER_START The SCTP_CMD_TIMER_START handler checks timer_pending() before calling timer_reduce(). The timer can expire and detach between these operations, causing timer_reduce() to rearm the timer without taking the association reference required for the newly armed timer. The timer callback later unconditionally drops its association reference, which can leave the association reference count unbalanced and result in use-after-free during association teardown. Use the return value of timer_reduce() to determine whether the timer was actually armed. Take the association reference only when timer_reduce() successfully starts a new timer, closing the race between checking the timer state and rearming it. This issue was reported by Nico Yip (@cyeaa) working with TrendAI Zero Day Initiative.

• Linux kernel: the record marks 4.19.126 through less than 4.20 as affected.
• Linux kernel: the record marks 5.4.44 through less than 5.5 as affected.
• Linux kernel: the record marks 5.6.16 through less than 5.7 as affected; 5.7 is also marked affected in a separate entry.
• The updated record lists branch-specific fixed boundaries at 5.10.271, 5.15.222, 6.1.189, 6.6.158, 6.12.111, 6.18.53 and 7.2.7. The corresponding branches are affected before their respective boundaries. 7.3-rc1 is listed as affected, while 7.3 is listed as unaffected by the original fix commit.
• The record also marks multiple Git ranges and several standalone Git revisions as affected. A fixed state in one branch must not be generalized to another branch or revision.
• Microsoft VEX marks azl3 kernel 0:6.6.157.1-1.azl3 for Azure Linux 3.0 as known affected and azl3 kernel 0:6.6.158.1-1.azl3 as fixed; Azure Linux 4.0 remains under investigation.
• Red Hat VEX lists multiple kernel products and OpenShift components as known affected, with no fix available in that VEX entry for the listed products. RHEL 6 products are separately marked out of support.

The flaw is in the SCTP SCTP_CMD_TIMER_START handler. The handler checks timer_pending() and then calls timer_reduce(). The timer can expire and detach between those operations, allowing timer_reduce() to rearm it without taking the association reference required for the new timer. The timer callback later drops its association reference unconditionally, which can unbalance the reference count and lead to use-after-free during association teardown.

The fix uses the return value of timer_reduce() to determine whether the timer was actually armed, and takes the association reference only when that operation successfully starts a new timer. Exploitation requires the SCTP path to be reachable and the attacker to win a very narrow timing window between the state check and timer rearming. The record establishes network reachability without authentication or user interaction; it does not establish a complete packet sequence or reliable arbitrary code execution.

• Reachability: The flaw can be triggered remotely through SCTP traffic. The supplied assessment describes an unauthenticated network peer and no user interaction.
• Preconditions: The attacker must win a tight TOCTOU race while an SCTP timer expires during association closing or teardown. This makes exploitation high complexity and difficult to perform reliably.
• Deployment scope: Red Hat states that the SCTP kernel module is not loaded by default in its products and that systems not running SCTP-dependent services are not exposed under the described condition.
• Exploitation status: The supplied record does not establish observed exploitation or a public exploit. The absence of such a status should not be treated as proof that a system is safe.

The bug can cause an association reference to be dropped too many times, freeing an sctp_association while another kernel path can still use it, followed by use-after-free or refcount underflow. Direct outcomes can include a kernel crash, denial of service or host instability. Because the freed object is kernel memory, a use-after-free could affect kernel integrity and confidentiality, but the record does not confirm a reliable exploit for code execution or privilege escalation. The impact remains within the kernel's security boundary under the available assessment and depends on the host actually exposing SCTP.

• SCTP-enabled servers could crash or lose service if the race corrupts the lifetime of an SCTP association.
• Because the flaw is in the kernel and involves use-after-free, successful corruption could destabilize the entire host rather than only the SCTP-serving process.
• The concrete data or privilege consequences depend on whether freed memory can be reused in a useful way; the record does not establish a specific compromise, data disclosure or privilege-escalation scenario.
• Hosts that do not use SCTP have a lower exposure condition, but administrators should still verify the kernel package instead of relying only on whether the SCTP module is currently loaded.

1. Prioritize an upstream SCTP patch or the kernel update supplied by the operating-system vendor. For maintained branches with recorded boundaries, use the applicable fixed boundary at 5.10.271, 5.15.222, 6.1.189, 6.6.158, 6.12.111, 6.18.53 or 7.2.7. Do not use one branch's boundary to establish the status of another branch.
2. For Azure Linux 3.0, update from azl3 kernel 0:6.6.157.1-1.azl3 to azl3 kernel 0:6.6.158.1-1.azl3, which Microsoft marks as the vendor fix.
3. For kernels in the 4.19.126 through less than 4.20, 5.4.44 through less than 5.5, or 5.6.16 through less than 5.7 ranges, apply the corresponding kernel update or upstream patch. Because 5.7 is separately marked affected, do not assume that moving to 5.7 alone remediates the issue.
4. Check the distributor advisory for the exact kernel and kernel-rt package in use. Red Hat currently identifies multiple downstream products as affected and lists some products without a fix in its VEX record; RHEL 6 is marked out of support.
5. If patching is delayed, identify SCTP-dependent services before considering whether SCTP can be kept unloaded or restricted. Not running SCTP-dependent services may remove the exposure condition described by Red Hat, but it is not a substitute for updating the kernel.

1. Inventory the running kernel, kernel package and, where available, the corresponding SCTP commit or patch level. Compare each branch with the affected and fixed boundaries in affected_summary.
2. Determine whether the host loads the SCTP module or runs an application that provides or uses SCTP. This identifies likely exposure but does not prove that the kernel is patched.
3. For source builds or internally maintained kernels, inspect the SCTP_CMD_TIMER_START handler and verify that the association reference is taken only when timer_reduce() actually starts a new timer.
4. Review kernel logs, crash dumps and fault reports for SCTP association teardown failures, refcount imbalance, use-after-free reports or kernel crashes as supplemental monitoring. These are precautionary signals, not confirmed indicators of compromise.
5. Do not treat the absence of relevant log evidence as proof that the vulnerability is absent or was not exploited.