CVE-2026-99128

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

sctp: validate chunk length in the inqueue parser

SCTP chunks always include a four-byte generic header, but sctp inq pop() currently accepts shorter declared lengths. A zero-length chunk leaves chunk end at the current header.

When ASCONF is covered by the association's SCTP-AUTH policy, sctp assoc bh rcv() can continue before the state machine performs its normal chunk-length check. sctp inq pop() then returns the same malformed chunk repeatedly and the receive softirq can lock up.

A remote SCTP peer can trigger this after establishing an association on a kernel built with CONFIG IP SCTP and configured with net.sctp.addip enable=1 and net.sctp.auth enable=1. The reproducer did not require application credentials, a shared SCTP AUTH key, or net.sctp.addip noauth enable=1.

On commit f967455fb2a5 ("seg6: reset IP6CB after IPv6 decapsulation"), one zero-length ASCONF caused repeated watchdog soft-lockup reports in a two-vCPU KVM guest. All 3 pre-trigger health probes succeeded, while 36 of 37 post-trigger probes failed. With this change, all 37 post-trigger probes succeeded and no equivalent soft-lockup signature appeared.

Reject chunks shorter than the generic SCTP header at the shared inqueue parser boundary. Mark the packet for discard before either caller can continue processing it, while preserving the four-byte generic minimum. Declared-length 1 through 4 controls and kernel-generated ASCONF traffic remained healthy. The patched sctp hello selftest passed for IPv4 and IPv6.

The complete private reproducer and validation evidence are available directly to maintainers on request.