CVE-2026-64551

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: validate STALE_COOKIE cause length before reading staleness<br /> <br /> When an ERROR chunk with a STALE_COOKIE cause is received in the<br /> COOKIE_ECHOED state, sctp_sf_do_5_2_6_stale() reads the 4-byte Measure<br /> of Staleness that follows the cause header:<br /> <br /> err = (struct sctp_errhdr *)(chunk-&gt;skb-&gt;data);<br /> stale = ntohl(*(__be32 *)((u8 *)err + sizeof(*err)));<br /> <br /> err is the first cause in the chunk, not the STALE_COOKIE cause that<br /> caused the dispatch, and nothing guarantees the staleness field is<br /> present. sctp_walk_errors() only requires a cause to be as long as the<br /> 4-byte header, so for a STALE_COOKIE cause of length 4 the read runs<br /> past the cause, and for a minimal ERROR chunk past skb-&gt;tail. The value<br /> is echoed to the peer in the Cookie Preservative of the reply INIT,<br /> leaking uninitialized memory.<br /> <br /> sctp_sf_cookie_echoed_err() already walks to the STALE_COOKIE cause, so<br /> check its length there and pass it to sctp_sf_do_5_2_6_stale(), which<br /> reads that cause instead of the first one. A STALE_COOKIE cause too<br /> short to hold the staleness field is discarded.<br /> <br /> The read is reachable by any peer that can drive an association into<br /> COOKIE_ECHOED, including an unprivileged process using a raw SCTP socket<br /> in a user and network namespace.