Cloudanix VulnDB

CVE-2026-98614

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in Linux network code can make the system freeze when handling certain kinds of network connections, potentially knocking services offline until the machine is restarted or updated.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Denial of service
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Logic error in sctp_assoc_update_retran_path allows an infinite loop when all remaining SCTP transports are in the UNCONFIRMED state because the state filter precedes the wrap-around check and a missing NULL guard can leave retran_path unset.

Why it matters to the business

Systems relying on SCTP may experience sudden unresponsiveness or high CPU usage in the networking stack, interrupting services that depend on reliable multi-homed transport and requiring emergency restarts or kernel updates.

How an attack unfolds

An attacker establishes an SCTP association and maneuvers all peer transports into the UNCONFIRMED state; when the kernel later invokes retransmit-path selection the loop condition never terminates, producing a livelock that consumes a CPU core until the process or system is reset.

How to fix it

Apply the upstream kernel commit that reorders the state check, restores the wrap-around test, and adds the NULL guard; rebuild and reboot to a fixed kernel version containing this change.

How to confirm the fix worked

Confirm the presence of the corrected sctp_assoc_update_retran_path logic in the running kernel source or binary; exercise SCTP associations under all-UNCONFIRMED conditions and verify the function returns without spinning.

Typical attack path

  1. Establish SCTP association with multiple paths
  2. Force or wait for all paths to enter UNCONFIRMED state
  3. Trigger retransmit-path update via packet loss or timeout
  4. Observe livelock consuming CPU with no forward progress

How to detect it

Look for prolonged kernel CPU usage on hosts running SCTP without corresponding network progress; examine kernel stack traces showing repeated execution inside sctp_assoc_update_retran_path.

What your security team should do

  • Prioritize kernel updates on any system exposing SCTP sockets
  • Monitor for sustained high kernel CPU on SCTP-enabled hosts
  • Limit SCTP exposure to trusted networks until patched

The record

In the Linux kernel, the following vulnerability has been resolved: sctp: avoid livelock while updating retransmit path sctp_assoc_update_retran_path() can loop forever when every remaining transport, including retran_path, is SCTP_UNCONFIRMED: the state check runs before the wraparound test, so the loop cannot observe that it has completed a full pass. Fix this by considering a transport only when it is not UNCONFIRMED, then checking whether the walk has returned to retran_path. This makes the full-pass termination independent of the transport state while preserving the existing fallback selection semantics. Also restore the NULL guard around the retran_path assignment. In the all-UNCONFIRMED case there is no eligible replacement transport, and installing NULL would leave later retransmit-path users and the debug print with a NULL path.

Affected packages

Ecosystem Package Introduced Fixed