HIGH
sctp RetransPath Livelock
CVE-2026-98614
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
01Description
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.
02KernelScan AI Analysis
Risk summary
A remote attacker who can establish an SCTP association with multihoming can force all transport paths into the UNCONFIRMED state, triggering an infinite loop in the kernel's retransmission path selection logic. This causes a CPU core to hang indefinitely, resulting in a denial of service. No privileges or local access are required — only network connectivity to an SCTP listener.
Vulnerability analysis
The SCTP subsystem's retransmission path selection function can enter an infinite loop when all network paths for an association are in an unconfirmed state. The original code skipped unconfirmed paths before checking whether it had completed a full pass through the path list, so the termination condition was never reached. The fix ensures the loop checks for a full pass on every iteration regardless of path state, and only considers confirmed paths as candidates. A guard was also added to prevent setting the retransmission path to null when no eligible path exists.
Lifecycle
03Fix Versions
| Branch | Introduced | Fixed in | Patch commit |
|---|---|---|---|
| 3.10 | 3.10.106 | 3.11 | 3fe624c38436 |
| 3.12 | 3.12.71 | 3.13 | 43410c1f2db5 |
| 5.10 | — | 5.10.271 | d893a7cc1cb4 |
| 5.15 | — | 5.15.222 | 83b1a7f9e718 |
| 6.1 | — | 6.1.189 | 173610fff550 |
| 6.12 | — | 6.12.112 | ddc34cc0834c |
| 6.18 | — | 6.18.55 | d2c31b837406 |
| 6.6 | — | 6.6.158 | c9338057df10 |
| 7.2 | — | 7.2.9 | — |
| mainline | — | 7.3 | — |
| cip/5.10 | — | 5.10.271-cip78 | 3fe624c38436 |
| cip/6.1 | — | 6.1.189-cip61 | d893a7cc1cb4 |
| cip/6.1-rt | — | 6.1.189-cip61-rt32 | d893a7cc1cb4 |
| cip/6.12 | — | 6.12.112-cip33 | 173610fff550 |
04CIP Kernels
State of the newest release of each Civil Infrastructure Platform SLTS tree, from CIP's own fix records.
| CIP tree | State |
|---|---|
| cip/6.12 | Fixed in 6.12.112-cip33 |
| cip/6.1 | Fixed in 6.1.189-cip61 |
| cip/6.1-rt | Fixed in 6.1.189-cip61-rt32 |
| cip/5.10 | Fixed in 5.10.271-cip78 |
| cip/5.10-rt | Affected — no CIP fix yet (latest 5.10.268-cip77-rt34) |