CVE-2026-98548 in Linux
Summary
by MITRE • 10/18/2026
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/18/2026
The Linux kernel contains a critical use-after-free vulnerability within the Stream Control Transmission Protocol (SCTP) implementation that affects systems running vulnerable versions of the kernel. This flaw is triggered when an SCTP association enters the COOKIE-ECHOED state and receives a bundled packet containing both an ERROR chunk indicating a stale cookie and subsequent DATA chunks from a non-primary address. The processing logic for handling this specific error condition initiates a retry path designed to manage the stale cookie situation, which involves removing all non-primary transport endpoints associated with the peer. However, the implementation fails to account for the fact that these removal operations occur while the packet is still being processed and its constituent chunks are actively referencing the very transport structures they help destroy.
The technical root cause lies in a race condition between state management and memory lifecycle within the SCTP stack. When the stale-cookie error chunk is processed, it triggers commands to delete non-primary transports from the association's peer list. This deletion process eventually leads to the freeing of the underlying sctp_transport structures via RCU mechanisms once the receive reference count drops. Crucially, this happens while other chunks in the same bundled packet are still being handled by the kernel. Specifically, after the transport is removed and its memory freed, subsequent processing steps such as registering the source address for last data reception unconditionally overwrite association state with pointers to the now-freed transport object. This creates a dangling pointer that remains valid within the context of the current packet's processing loop but becomes invalid once the RCU grace period expires or when accessed by later operations like Forward-TSN handling or SACK generation.
The operational impact of this vulnerability is severe, as it allows for arbitrary code execution or system crashes through memory corruption. A malicious SCTP peer can craft a specially designed packet that exploits this sequence to trigger a use-after-free condition. The kernel attempts to read from or write to the freed memory region during subsequent state machine transitions, such as generating Selective Acknowledgments (SACKs) or processing Forward-TSN chunks. This activity is detectable via Kernel Address Sanitizer (KASAN) reports showing slab-use-after-free errors where reads occur at addresses within recently freed kmalloc regions. The vulnerability requires no special privileges to exploit; any network-accessible SCTP service can be targeted by an external attacker, and potentially even local unprivileged users if they have the ability to send raw packets or interact with relevant sockets depending on system configuration.
This issue persists despite previous mitigation attempts like commit 03a9d10ecf71 which aimed to drop chunks associated with removed transports. That earlier fix addressed races where transport removal happened before packet processing began, but it did not cover the scenario where a chunk within the same packet causes its own transport's destruction during processing. The current patch resolves this by discarding the remainder of the bundled packet once the stale-cookie error has been processed and non-primary transports removed. This ensures that subsequent chunks do not operate against invalidated state or freed memory, forcing the peer to retransmit valid packets under correct conditions rather than allowing corrupted processing paths to proceed.
From a classification perspective, this vulnerability aligns with CWE-416 Use After Free, as it involves accessing memory after it has been made available for reuse without proper validation of its validity. In terms of attack vectors and techniques, the exploitation path relates to ATT&CK Tactic TA0002 Execution through potential code execution via kernel privilege escalation or denial of service via system crash. The specific mechanism also touches upon CWE-367 Time-of-check Time-of-use (TOCTOU) race conditions inherent in how state is updated relative to resource deallocation during high-throughput packet processing.
To mitigate this risk, administrators should apply the latest available kernel updates that include the fix for discarding remaining chunks on stale-cookie errors. Organizations relying on SCTP services must ensure their systems are patched against this specific flaw to prevent potential remote exploitation leading to system compromise or instability. Regular monitoring of network traffic for anomalous SCTP packet structures can also serve as a defensive measure, although patching remains the primary and most effective remediation strategy given the low barrier to entry for attackers exploiting this kernel-level memory safety issue.