CVE-2026-98548

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

sctp: discard the rest of the packet on a stale-cookie error

When an association is in COOKIE-ECHOED state and the peer sends a bundled [ERROR(Stale Cookie)][DATA] packet from one of its non-primary addresses, processing the ERROR chunk takes the non-fatal stale-cookie retry path sctp sf do 5 2 6 stale(), which queues SCTP CMD DEL NON PRIMARY while keeping the association alive. sctp cmd del non primary() removes every non-primary transport - including the very transport this packet arrived on, which is still referenced by the receive lookup and shared by all chunks of the packet via chunk->transport.

sctp assoc rm peer() does redirect asoc->peer.last data from away from the removed transport, but right afterwards the bundled DATA chunk makes sctp assoc bh rcv() re-register asoc->peer.last data from = chunk->transport unconditionally, undoing the redirection with the just-removed transport.

Once the packet is done, the receive reference is dropped and the transport is RCU-freed, while the surviving association keeps the dangling last data from. A later FWD-TSN (or the delayed SACK timer) makes sctp gen sack() dereference it (->param flags and friends), and sctp make sack()/sctp outq select transport() may write to the freed object and link it into the live transport list. This is a use-after-free triggerable by any malicious SCTP peer (or a local unprivileged user acting as one) with no capabilities required:

BUG: KASAN: slab-use-after-free in sctp do sm+0x498a/0x5660 Read of size 4 at addr ffff88800e1e356c by task poc/115 Call Trace: sctp do sm <- sctp assoc bh rcv <- sctp inq push <- sctp rcv <- ip protocol deliver rcu <- ip rcv Allocated: sctp transport new <- sctp assoc add peer <- sctp process init (INIT-ACK processing) Freed: kfree <- sctp transport destroy rcu <- rcu core (call rcu queued by sctp transport put at end of sctp rcv) The buggy address is located 364 bytes inside of freed 1024-byte region [ffff88800e1e3400, ffff88800e1e3800), cache kmalloc-1k

Note that commit 03a9d10ecf71 ("sctp: drop a chunk if its transport was removed") only covers the window between the receive lookup and the chunk processing (e.g. an ASCONF DEL-IP racing the socket backlog); here the transport is removed while the packet is being processed, by an earlier chunk of the same packet, so the drop in sctp inq push() does not reach this path. Verified with the bundled [ERROR(Stale Cookie)][DATA] + FWD-TSN reproducer: the KASAN report above still fires with that commit applied, and is gone with this patch on top.

Fix it by discarding the rest of the packet on this path, as suggested by Xin. After the stale-cookie ERROR has sent the association back to COOKIE-WAIT and removed the non-primary transports, the remaining chunks of the packet can only run against the restarted handshake while referencing the removed arrival transport through chunk->transport: besides the last data from registration above, sctp cmd setup t2() and the sctp make *() reply builders would also copy that pointer into association-lifetime state that sctp assoc rm peer() has already sanitized. Let the peer retransmit them, in line with what sctp inq push() does for chunks whose transport was removed before processing.