Cloudanix VulnDB

CVE-2026-98548

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A bug in the Linux network code that handles certain connection packets can let an attacker crash the whole system or possibly take it over.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Low
Impact
Full Compromise
Component
OS kernel
Class
Use After Free
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Use-after-free in the Linux kernel SCTP implementation where removal of a non-primary transport during bundled ERROR(DATA) processing leaves a dangling last_data_from pointer that is later dereferenced in sctp_gen_sack and related functions, enabling slab corruption.

Why it matters to the business

Remote attackers can trigger kernel crashes or potential code execution on Linux systems exposing SCTP, causing denial of service or full host compromise; the low EPSS and five-day-old disclosure indicate limited current exploitation but require urgent attention on any SCTP-enabled infrastructure.

How an attack unfolds

A malicious SCTP peer sends a bundled packet containing an ERROR(Stale Cookie) chunk followed by DATA from a non-primary address during the COOKIE-ECHOED state; processing removes the arrival transport while the packet is still being handled, leaving a freed object referenced by association state that is later dereferenced by FWD-TSN or delayed SACK handling.

How to fix it

Apply the upstream kernel patch that discards remaining chunks after a stale-cookie ERROR; upgrade to a distribution kernel containing the fix once released.

How to confirm the fix worked

Confirm the fix is present by inspecting the sctp_sf_do_5_2_6_stale path for early packet discard logic; re-run the bundled ERROR+DATA reproducer under KASAN and verify absence of slab-use-after-free reports.

Typical attack path

  1. Reach COOKIE-ECHOED association state from a non-primary address
  2. Transmit bundled [ERROR(Stale Cookie)][DATA] packet
  3. Send subsequent FWD-TSN or allow SACK timer to fire
  4. Trigger use-after-free in sctp_do_sm during sack generation or transport selection

How to detect it

Inspect kernel logs for KASAN slab-use-after-free reports referencing sctp_do_sm, sctp_assoc_bh_rcv, or sctp_inq_push; correlate with SCTP traffic containing ERROR chunks immediately followed by DATA chunks from non-primary addresses.

What your security team should do

  • Prioritize kernel updates containing the SCTP stale-cookie discard change on all systems that enable SCTP
  • Disable the SCTP protocol module if network services do not require it
  • Add kernel crash and KASAN monitoring for sctp_do_sm and sctp_assoc_bh_rcv symbols

The record

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.

Affected packages

Ecosystem Package Introduced Fixed