CVE-2026-99128 in Linux
Summary
by MITRE • 10/28/2026
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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/28/2026
A critical vulnerability exists within the Stream Control Transmission Protocol implementation in the Linux kernel, specifically affecting the input queue parser responsible for processing incoming SCTP chunks. The core technical flaw lies in the sctp_inq_pop function, which fails to adequately validate the length field of received SCTP chunks against the minimum required size defined by the protocol specification. Every valid SCTP chunk must begin with a four-byte generic header containing type, length, and checksum fields. However, the vulnerable code path accepts declared lengths that are shorter than this mandatory four-byte threshold. This oversight allows an attacker to craft malformed packets where the declared chunk length is zero or otherwise insufficient, leading to incorrect pointer arithmetic within the kernel's packet processing logic. When a zero-length ASCONF chunk is processed under specific configuration conditions, the internal state machine does not perform its standard validation checks before proceeding, resulting in the parser repeatedly returning the same malformed chunk data rather than discarding it as invalid.
The operational impact of this vulnerability is severe, primarily manifesting as a denial-of-service condition through kernel soft-lockups and system hangs. When an association is established with both IPv4/IPv6 add IP support (net.sctp.addip_enable) and authentication extensions (net.sctp.auth_enable) enabled, the receive soft interrupt can become trapped in an infinite loop processing these malformed chunks. This behavior effectively freezes the network stack for that specific socket or potentially impacts broader system stability depending on resource contention. Empirical testing demonstrates significant performance degradation; in controlled environments such as two-vCPU KVM guests, triggering this flaw results in repeated watchdog soft-lockup reports and a drastic drop in successful health probes from thirty-seven to only one. The vulnerability is remotely exploitable by any peer capable of establishing an SCTP association with the target host, requiring no application credentials or shared authentication keys due to the specific sequence of state machine execution that bypasses normal length checks during the initial phases of chunk processing under ASCONF handling.
From a classification perspective, this flaw aligns with CWE-20 Improper Input Validation and CWE-134 Use of Externally-Controlled Format String or similar logic errors leading to resource exhaustion. In terms of attack vectors, it corresponds to MITRE ATT&CK techniques related to Denial of Service via infinite loops or kernel panics, specifically leveraging network protocol parsing weaknesses. The vulnerability highlights the risks associated with complex state machines in network protocols where early-stage processing may bypass later validation layers if input constraints are not strictly enforced at the entry point. To mitigate this risk, developers have implemented a fix that rejects any SCTP chunk with a declared length shorter than the four-byte generic header minimum directly within the shared inqueue parser boundary. This ensures that malformed packets are marked for immediate discard before they can propagate further into the association state machine or trigger repeated processing cycles.
The remediation strategy preserves normal functionality by ensuring that valid control traffic and kernel-generated ASCONF messages continue to operate correctly, as confirmed by passing self-tests for both IPv4 and IPv6 configurations. System administrators should apply this patch immediately on systems running kernels with CONFIG_IP_SCTP enabled and where SCTP authentication features are active. Until the update is applied, monitoring network logs for unusual patterns of short-length SCTP packets or observing soft-lockup warnings in kernel dmesg outputs can serve as indicators of potential exploitation attempts. The fix restores robustness to the protocol implementation by enforcing strict adherence to RFC standards regarding chunk structure at the earliest possible stage of packet ingestion, thereby preventing the infinite loop condition that leads to service disruption.