CVE-2023-53590 in Linux
Summary
by MITRE • 10/04/2025
In the Linux kernel, the following vulnerability has been resolved:
sctp: add a refcnt in sctp_stream_priorities to avoid a nested loop
With this refcnt added in sctp_stream_priorities, we don't need to traverse all streams to check if the prio is used by other streams when freeing one stream's prio in sctp_sched_prio_free_sid(). This can avoid a nested loop (up to 65535 * 65535), which may cause a stuck as Ying reported:
watchdog: BUG: soft lockup - CPU#23 stuck for 26s! [ksoftirqd/23:136]
Call Trace: <TASK> sctp_sched_prio_free_sid+0xab/0x100 [sctp]
sctp_stream_free_ext+0x64/0xa0 [sctp]
sctp_stream_free+0x31/0x50 [sctp]
sctp_association_free+0xa5/0x200 [sctp]
Note that it doesn't need to use refcount_t type for this counter, as its accessing is always protected under the sock lock.
v1->v2: - add a check in sctp_sched_prio_set to avoid the possible prio_head refcnt overflow.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 04/27/2026
The vulnerability CVE-2023-53590 addresses a critical nested loop condition within the Stream Control Transmission Protocol (SCTP) implementation of the Linux kernel. This issue manifests in the sctp_stream_priorities structure where the absence of proper reference counting leads to excessive computational overhead during stream priority cleanup operations. The flaw specifically occurs in the sctp_sched_prio_free_sid function which must traverse all streams to verify if a particular priority value is still in use by other streams. This design creates a quadratic complexity scenario where the number of iterations can reach up to 65535 * 65535, resulting in severe system performance degradation and potential system lockup conditions.
The technical implementation flaw stems from the lack of reference counting mechanism in the sctp_stream_priorities structure, which forces the kernel to perform exhaustive searches through all available streams whenever a stream priority needs to be freed. This nested loop behavior directly violates the principle of efficient resource management and creates a denial of service vulnerability through resource exhaustion. The issue was identified through watchdog monitoring that detected a soft lockup condition on CPU#23 where the system became unresponsive for 26 seconds due to the excessive loop iterations. The call trace demonstrates the execution path leading to the problem through sctp_sched_prio_free_sid, sctp_stream_free_ext, sctp_stream_free, and finally sctp_association_free functions, all within the SCTP subsystem.
The operational impact of this vulnerability extends beyond simple performance degradation to potentially complete system lockup scenarios that can render the affected system unusable. The nested loop condition creates a situation where the kernel's soft lockup detector triggers, indicating that a CPU has been stuck for an extended period, typically 26 seconds in the reported instance. This type of vulnerability represents a classic example of inefficient algorithmic complexity that can be exploited to cause denial of service conditions, particularly in environments where SCTP is heavily utilized for real-time communications or high-throughput applications. The vulnerability affects systems running Linux kernels with SCTP support and can be triggered through normal SCTP association management operations.
The mitigation strategy implemented in the fix involves adding a reference counter to the sctp_stream_priorities structure to eliminate the need for traversing all streams during priority cleanup operations. This approach follows the established pattern of using reference counting to avoid expensive search operations, which is a common anti-pattern in kernel development that can lead to quadratic complexity issues. The solution specifically avoids using the refcount_t type since all accesses are already protected by the socket lock, demonstrating proper understanding of synchronization requirements. Additionally, the patch includes a defensive check in sctp_sched_prio_set to prevent potential refcnt overflow conditions, showing comprehensive consideration of edge cases that could arise from the new reference counting mechanism. This fix aligns with CWE-126 (Buffer Over-read) and CWE-129 (Improper Validation of Array Index) categories, as it addresses improper validation of resource access patterns. The mitigation approach also reflects ATT&CK technique T1499.004 (Resource Exhaustion) by preventing the excessive resource consumption that would otherwise occur during the nested loop execution.