CVE-2026-98123

In the Linux kernel, the following vulnerability has been resolved:

sctp: fix soft lockup from unpadded ASCONF-ACK parameter iteration

sctp verify asconf() walks ASCONF-ACK parameters with sctp walk params(), which advances by SCTP PAD4(length), while the consumer sctp get asconf response() iterates the same parameters advancing by the raw length, without padding. A single odd-length parameter desynchronises the two walks and makes the consumer interpret attacker-controlled bytes at a misaligned offset.

When those bytes yield a length of zero, the while loop over asconf ack len makes no progress, spinning forever in softirq context, and the watchdog reports a soft lockup. All reads stay within the received skb, so the lockup is a pure remote denial of service. A remote peer can trigger it with a crafted ASCONF-ACK on an ADD-IP enabled association with an outstanding ASCONF (RFC 5061 section 4.1.2 requires the chunk to be authenticated, but the predefined empty key id 0 allows the peer to compute the same association HMAC from publicly exchanged parameters, so the gate does not help).

The SCTP PARAM ERR CAUSE case of sctp verify asconf() also performs no length check, letting a parameter without a complete error header reach the consumer, which reads errhdr.cause past the end of the parameter, an out-of-bounds read.

Reject SCTP PARAM ERR CAUSE parameters shorter than sizeof(struct sctp addip param) + sizeof(struct sctp errhdr) at the verifier, and advance the consumer iterator with the same padding rule as the verifier to keep the two walks in lockstep. The verifier change guarantees a complete error header in every ERR CAUSE parameter the consumer can see, so the consumer's asconf ack len check is dropped and it returns err param->cause directly. The consumer padding fix is still required because odd lengths remain valid for SCTP PARAM ERR CAUSE per RFC 5061.

The issue was found by ZeroHive, a vulnerability hunting agent at Tencent Yunding Lab.