CVE-2026-98548

Received Received - Intake

Use-After-Free in Linux Kernel SCTP Stack

Publication date: 2026-10-18

Last updated on: 2026-10-19

Assigner: kernel.org

Description

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.

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published

2026-10-18

Last Modified

2026-10-19

Generated

2026-10-19

AI Q&A

2026-10-18

EPSS Evaluated

N/A

NVD

CVE-2026-98548

EUVD

EUVD-2026-103593

Affected Vendors & Products

Vendor	Product	Version / Range
Linux	Linux	1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
Linux	Linux	1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
Linux	Linux	1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
Linux	Linux	1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
Linux	Linux	1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
Linux	Linux	1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
Linux	Linux	1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
Linux	Linux	1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
Linux	Linux	2.6.12

Helpful Resources

Exploitability

CWE

KEV

CWE ID	Description
CWE-UNKNOWN

Attack-Flow Graph

Executive Summary

This is a use-after-free vulnerability in the Linux kernel's SCTP implementation. It occurs when an association is in a specific state and a peer sends a bundled error and data packet. Processing the error chunk removes a transport but later chunks in the same packet incorrectly reference the freed memory, leading to a kernel crash or potential code execution.

Detection Guidance

This vulnerability is specific to the Linux kernel's SCTP implementation and may not have direct detection commands. However, you can check your kernel version with 'uname -r' and verify if it is affected by comparing against patched versions. Monitor kernel logs for SCTP-related errors or crashes using 'dmesg | grep sctp'.

Impact Analysis

An attacker could exploit this to crash the system or potentially execute arbitrary code with kernel privileges. This requires network access to trigger via SCTP traffic, but no special permissions are needed. Local unprivileged users could also exploit it by acting as a malicious SCTP peer.

Compliance Impact

This vulnerability is a use-after-free flaw in the Linux kernel's SCTP implementation that could allow malicious actors to trigger memory corruption. While not directly tied to data protection standards like GDPR or HIPAA, such vulnerabilities could indirectly impact compliance by enabling unauthorized access or data exfiltration if exploited in systems handling sensitive data.

Mitigation Strategies

Apply the latest Linux kernel patches that address this issue. If immediate patching is not possible, consider disabling SCTP support if not required, or restrict network access to SCTP ports. Monitor vendor advisories for updates.

Hi! I’m here to help you understand CVE-2026-98548. Ask me anything about the vulnerability, its impact, or mitigation strategies.

0/70