EUVD-2026-103593
GHSA-3mq3-vc9v-9wmc
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessEstablish SCTP association in COOKIE-ECHOED state
-
DeliverySend bundled ERROR(Stale Cookie)+DATA from non-primary address
-
ExploitTrigger non-primary transport removal with dangling last_data_from
-
ExecutionSend FWD-TSN or await delayed SACK timer
-
ImpactUse-after-free read/write in kernel SCTP causing corruption or DoS
Vulnerability Assessment
| Exploitation Conditions | Requires the SCTP subsystem to be in use on the target, which is not the default on most Linux deployments. The attacker must act as an SCTP peer, bring an association into COOKIE-ECHOED state, and send a bundled [ERROR(Stale Cookie)][DATA] chunk from a NON-PRIMARY (multi-homed) transport address; the use-after-free is then reached via a following FWD-TSN chunk or the delayed SACK timer. No authentication or capabilities are required (CVSS PR:N), and no user interaction is needed. Limiting factors beyond raw CVSS: SCTP must be enabled/used, and the association must be multi-homed so a non-primary transport exists to be removed - both reduce realistic exposure despite the network vector. |
| Impact | Signals conflict sharply and must be weighed together. The input CVSS is 9.8 (AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:H), and the vuln.today Decision label is act_now with an available vendor patch, which argues for prompt remediation. However, EPSS is only 0.21% (11th percentile), the CVE is NOT on CISA KEV, and no public exploit link is present in the references - so there is no evidence of active or widespread exploitation. The high CVSS is justified in principle: this is a kernel use-after-free (effectively CWE-416, though CWE is listed N/A) that the commit says is triggerable by any malicious SCTP peer or a local unprivileged user with no capabilities required, and the freed object is both read and written, so info disclosure, memory corruption, and DoS are all plausible. The critical caveat the raw score hides is reachability: the flaw lives in the SCTP stack, which is not loaded or used in most production Linux systems, and the attacker must drive a real SCTP association into COOKIE-ECHOED state over a multi-homed (non-primary address) path. Net assessment: a genuinely serious kernel bug worth patching per the act_now label, but the low EPSS and the narrow SCTP attack surface mean real-world exposure is far smaller than a 9.8 against a ubiquitous product would suggest - prioritize by whether SCTP is actually in use. |
| Exploit ScenarioDerived | A malicious SCTP peer (or a local unprivileged user acting as one) establishes an association and drives it into COOKIE-ECHOED state, then sends a bundled [ERROR(Stale Cookie)][DATA] packet from a non-primary address followed by a FWD-TSN. The stale-cookie path removes the arrival transport while later chunks of the same packet re-register the now-freed pointer as asoc->peer.last_data_from, and a subsequent SACK/FWD-TSN dereferences and writes to the freed kmalloc-1k object, corrupting kernel memory. The commit describes a working KASAN-verified reproducer, but it is not published as public exploit code. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 24, 2026
A use-after-free in the Linux kernel's SCTP receive path lets a remote attacker who acts as an SCTP peer crash or potentially corrupt kernel memory by sending a bundled [ERROR(Stale Cookie)][DATA] packet from a non-primary address of a multi-homed association, after which a FWD-TSN chunk or the delayed SACK timer dereferences a transport that has already been RCU-freed; both a remote peer and a local unprivileged user acting as one can trigger it, and no authentication, capabilities or user interaction are required (CVSS 3.1 AV:N/AC:L/PR:N/UI:N, score 9.8). Exposure is constrained in practice because SCTP is not enabled or used by default on most Linux deployments, and the association must be multi-homed so that a non-primary transport exists to be removed. No public exploit was identified at time of analysis and there is no CISA KEV entry, while EPSS is low at 0.21% (11th percentile); the priority signal is nonetheless act_now, and vendor patches are available for the affected stable branches.
RemediationAI
Apply the vendor-released kernel updates: 5.10.271, 5.15.222, 6.1.189, 6.6.158, 6.12.112, 6.18.55, 7.2.9 or 7.3-rc5, taken from the stable commits listed in the cveorg references (for example https://git.kernel.org/stable/c/c0af3fd150fdc43821df3bb77e5ec74faf4dfc7a), or obtain the equivalent backport from your distribution's kernel advisory. Because the patch is the complete fix for a use-after-free held in association lifetime state, systems that cannot update immediately should reduce exposure by removing SCTP where it is not needed - unload the module and blacklist it (modprobe -r sctp plus a blacklist entry) - with the side effect of breaking any workload that depends on SCTP, such as telecom/LTE signalling, some VPN and firewall products, and SCTP-carrying container or storage traffic; alternatively filter SCTP at the network edge or with netfilter so only trusted peers can reach the host, accepting that this does not fix the bug and that any permitted SCTP peer on a multi-homed association can still reach the trigger. SCTP is not enabled or used by default on most Linux deployments, so confirming whether the module is loaded is the fastest way to triage priority.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The flaw lives in the SCTP state machine handling of the non-fatal stale-cookie retry path. When an association sits in COOKIE-ECHOED and a peer bundles an ERROR(Stale Cookie) chunk ahead of a DATA chunk in the same packet, sctp_sf_do_5_2_6_stale() queues SCTP_CMD_DEL_NON_PRIMARY while keeping the association alive; sctp_cmd_del_non_primary() then removes every non-primary transport, including the very transport the 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() redirects asoc->peer.last_data_from away from the removed transport, but the trailing bundled DATA chunk causes sctp_assoc_bh_rcv() to re-register asoc->peer.last_data_from = chunk->transport unconditionally, undoing the redirection against the transport that was just removed. Once the packet completes, the receive reference is dropped and the transport is RCU-freed, yet the surviving association retains the dangling last_data_from; a later FWD-TSN or the delayed SACK timer drives sctp_gen_sack() to read ->param_flags and related fields, and sctp_make_sack()/sctp_outq_select_transport() can write into the freed object and link it into the live transport list, as shown by the KASAN slab-use-after-free report in sctp_do_sm reached via sctp_assoc_bh_rcv, sctp_inq_push and sctp_rcv. The supplied record carries no CWE identifier, but the defect class is a use-after-free (CWE-416) of an sctp_transport object allocated in kmalloc-1k by sctp_transport_new during INIT-ACK processing. The earlier fix 03a9d10ecf71 ("sctp: drop a chunk if its transport was removed") only covers the window between the receive lookup and chunk processing, such as an ASCONF DEL-IP racing the socket backlog; because here the transport is removed while the packet is being processed by an earlier chunk of the same packet, that drop in sctp_inq_push() does not reach this path. The upstream fix discards the remainder of the packet after the stale-cookie ERROR has returned the association to COOKIE-WAIT, leaving the peer to retransmit, in line with the existing inq_push behaviour. As the trigger is a multi-chunk packet from a non-primary transport, exploitation depends on deployment details: confirmed is that any SCTP-capable peer (or a local unprivileged process acting as one) on an association that is multi-homed can reach the path per the supplied reproducer; unverified is any effect on single-homed associations, where no non-primary transport exists to be removed.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Remote SCTP peer with no capabilities drives the state and packet sequence (AV:N/AC:L/PR:N/UI:N); kernel UAF read/write yields high confidentiality, integrity and availability impact.
Primary rating from Vendor (Linux).
CVSS VectorVendor: Linux
Lifecycle Timeline
4DescriptionCVE.org
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.
Executive ViewAI
CVE-2026-98548 is a critical memory-safety flaw in the Linux kernel's SCTP networking code that a remote peer can trigger without credentials or user interaction, potentially crashing or corrupting systems. Leadership should care because any Linux fleet running SCTP is exposed at the network edge, though real-world risk is narrowed by SCTP rarely being enabled by default and the low (0.21%) likelihood of exploitation noted at analysis. Prioritize inventorying SCTP exposure and patching affected stable kernels.
Apply vendor patch. If immediate patching is not possible, disable or blacklist the sctp kernel module on hosts where SCTP is not required, and restrict network reachability to any SCTP services.
Threat Intelligence Overview
NVD
CVE.org
EPSS
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
Exploit-DB