CVE-2026-98614: sctp: avoid livelock while updating retransmit path
In the Linux kernel, the following vulnerability has been resolved:
sctp: avoid livelock while updating retransmit path
sctpassocupdateretranpath() can loop forever when every remaining transport, including retranpath, is SCTPUNCONFIRMED: 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 retranpath. 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 retranpath 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 Software
Event History
Frequently Asked Questions
Under what condition can the SCTP association update loop fail to terminate?
The loop can run indefinitely when every remaining SCTP transport, including the current retransmit path, is in the SCTP_UNCONFIRMED state. In that state, the original ordering prevents the walk from detecting that it has returned to the starting retransmit path.
What is the operational impact of the all-UNCONFIRMED transport case?
It can cause a livelock while the kernel updates an SCTP association's retransmit path. The affected logic could also install a NULL retransmit path when no eligible replacement exists, leaving later retransmit-path users and debug output with a NULL path.
What behavior does the fix preserve when no replacement retransmit transport is eligible?
The fix keeps the existing fallback selection semantics while making full-pass termination independent of transport state. It also retains a NULL guard so that no NULL retransmit path is assigned when all transports are unconfirmed.