CVE-2026-98548
CriticalCVSS 9.8Exploitation Probability (EPSS)
Low risk11th percentile - higher than 11% of all known CVEs
Summary
A use-after-free vulnerability exists in the Linux kernel's SCTP implementation. When an association is in COOKIE-ECHOED state and a peer sends a bundled [ERROR(Stale Cookie)][DATA] packet from a non-primary address, processing removes the transport the packet arrived on, but the subsequent DATA chunk re-registers a pointer to that freed transport. Later use of this dangling pointer (e.g., via FWD-TSN or delayed SACK timer) leads to a write to freed memory.
Risk Assessment
The vulnerability can be triggered by any malicious SCTP peer or a local unprivileged user acting as one, with no capabilities required, leading to kernel memory corruption and potential privilege escalation or denial of service (kernel panic).
Recommendation
Update the Linux kernel to a version containing the fix that discards the rest of the packet on a stale-cookie error. If immediate update is not possible, consider restricting access to SCTP services or disabling the sctp module if unused.
Other vulnerabilities in Linux kernel
See all- CVE-2026-99087Unknown
In the Linux kernel, dm-integrity has a NULL pointer dereference when a device with the SB_FLAG_DIRTY_BITMAP flag is activated in 'R' mode. The dm_integrity_resume function attempts to read the journal containing the bitmap, causing a crash. The fix skips writes to the device in 'R' mode during resume.
- CVE-2026-99086Unknown
In the Linux kernel, dm-integrity does not validate the superblock on resume, allowing a user to modify the superblock on the underlying device while the dm-integrity device is suspended. This can cause a mismatch in in-memory structure sizes and an out-of-bounds write past the journal, including a 512-byte write through a NULL pointer. The fix snapshots the validated superblock in the constructor and refuses to resume if the on-disk geometry changed.
- CVE-2026-99085Unknown
A Linux kernel vulnerability was fixed in the sched_ext scheduler that caused a CPU hotplug hang when a dying CPU's tasks remained in the BPF scheduler. Such tasks were still counted on the runqueue, but an inactive CPU no longer called ops.dispatch() and could not pull them back, blocking the hotplug thread and cpu_down() while holding cpu_hotplug_lock. The fix re-enqueues tasks on the offline rq to the local DSQ so balance_push() can move them off.
- CVE-2026-99084Unknown
In the Linux kernel, a flaw was fixed in iterate_dir() where the directory's i_rwsem lock was held during readdir even for immutable directories that are never removed. For the nullfs instance directory (shared across mount namespaces and kernel threads), a malicious reader could hold the lock indefinitely, blocking mkdir, lookups, and mounts for other users. A new FOP_IMMUTABLE flag was added to skip the lock for such directories.
- CVE-2026-99080Unknown
In the Linux kernel, clear_inode() has an xarray node leak that can be triggered, among other ways, via madvise. Rather than fixing the leaks where they occur, the fix calls xa_destroy(), which has the side effect of cycling the i_pages lock.
- CVE-2026-99076Unknown
A vulnerability in the Linux kernel's IPv6/UDP handling allowed off-path attackers to conduct a side-channel attack on the exception cache to discover the ephemeral port used by a connected UDP socket. Previously, an exception was only created if the UDP packet could be matched to an existing socket. The fix always creates an exception before attempting socket matching.
- CVE-2026-99075Unknown
In the Linux kernel, the rust_binder module has a bug in node refcount update on thread exit. When a thread exits via BINDER_THREAD_EXIT, a pending node refcount increment could be dropped because Node::cancel() and NodeWrapper::cancel() were no-ops. This desynchronizes the node's delivery and count state, and userspace may not receive the notification, potentially causing the node to never be freed.
- CVE-2026-99074Unknown
In the Linux kernel IPv4 subsystem, a null-ptr-deref occurs during PMTU update when a nexthop group shrinks. __ip_rt_update_pmtu() iterates over paths, and a concurrent nexthop replacement can cause fib_info_nhc() to return NULL, which is then dereferenced in update_or_create_fnhe(). This requires CAP_NET_ADMIN in the network namespace, but where unprivileged user namespaces are permitted, a local user can obtain it.
- CVE-2026-99073Unknown
In the Linux kernel IPv4 subsystem, a null-ptr-deref occurs during FIB exception dump when a nexthop group shrinks. fib_dump_info_fnhe() uses fib_info_num_path() as the loop bound, then fib_info_nhc() independently reloads nh->nh_grp; if RTM_NEWNEXTHOP replaces the group with fewer paths, fib_info_nhc() returns NULL and the dump dereferences it. The fix stops the walk when the indexed path is absent.
- CVE-2026-99072Unknown
In the Linux kernel IPv4 subsystem, a null-ptr-deref occurs during route notification sizing when a nexthop group shrinks. fib_nlmsg_size() checks fib_info_num_path() before each iteration, then fib_info_nhc() independently reloads nh->nh_grp; if RTM_NEWNEXTHOP replaces the group with fewer paths, fib_info_nhc() returns NULL and fib_nexthop_nlmsg_size() dereferences it. The fix stops sizing when the indexed path is absent.
Original NVD description (English source)
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.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS

