Excessive Platform Resource Consumption within a Loop The advisory has been revoked - it doesn't affect any version of package kernel-modules-extra  (opens in a new tab)


Threat Intelligence

EPSS
0.04% (11th percentile)

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications
  • Snyk IDSNYK-CENTOS8-KERNELMODULESEXTRA-13408399
  • published7 Oct 2025
  • disclosed4 Oct 2025

Introduced: 4 Oct 2025

CVE-2023-53590  (opens in a new tab)
CWE-1050  (opens in a new tab)

Amendment

The Centos security team deemed this advisory irrelevant for Centos:8.

NVD Description

Note: Versions mentioned in the description apply only to the upstream kernel-modules-extra package and not the kernel-modules-extra package as distributed by Centos.

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.