In the Linux kernel, the following vulnerability has been resolved:
sctp: validate STALE_COOKIE cause length before reading staleness
When an ERROR chunk with a STALECOOKIE cause is received in the COOKIEECHOED state, sctpsfdo526stale() reads the 4-byte Measure of Staleness that follows the cause header:
err = (struct sctp_errhdr *)(chunk->skb->data);
stale = ntohl(*(__be32 *)((u8 *)err + sizeof(*err)));
err is the first cause in the chunk, not the STALECOOKIE cause that caused the dispatch, and nothing guarantees the staleness field is present. sctpwalkerrors() only requires a cause to be as long as the 4-byte header, so for a STALECOOKIE cause of length 4 the read runs past the cause, and for a minimal ERROR chunk past skb->tail. The value is echoed to the peer in the Cookie Preservative of the reply INIT, leaking uninitialized memory.
sctpsfcookieechoederr() already walks to the STALECOOKIE cause, so check its length there and pass it to sctpsfdo526stale(), which reads that cause instead of the first one. A STALECOOKIE cause too short to hold the staleness field is discarded.
The read is reachable by any peer that can drive an association into COOKIE_ECHOED, including an unprivileged process using a raw SCTP socket in a user and network namespace.
{
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/64xxx/CVE-2026-64551.json"
}