CVE-2026-89477: Linux Kernel SCTP Privilege Escalation

CVE-2026-89477 Overview

CVE-2026-89477 is a NULL pointer dereference vulnerability in the Linux kernel's Stream Control Transmission Protocol (SCTP) implementation. The flaw resides in the RECONF (stream reconfiguration) completion path, where sctp_process_strreset_outreq(), sctp_process_strreset_addstrm_out(), and sctp_process_strreset_resp() dereference asoc->strreset_chunk->transport without confirming the chunk was actually transmitted. An unprivileged local process, or a remote peer sending a crafted RECONF chunk, can trigger the dereference from softirq context and panic the kernel.

Critical Impact
Remote or local attackers can crash the kernel through SCTP stream reset processing, producing a denial-of-service condition on any host with active SCTP associations.

Affected Products

Linux kernel (multiple stable branches referenced across eight upstream fix commits)
Distributions shipping vulnerable kernels with SCTP enabled (CONFIG_IP_SCTP=y or module)
Systems exposing SCTP endpoints such as telecom signaling gateways and clustering software

Discovery Timeline

2026-09-11 - CVE-2026-89477 published to NVD
2026-09-14 - Last updated in NVD database

Technical Details for CVE-2026-89477

Vulnerability Analysis

SCTP stream reconfiguration (RFC 6525) uses RECONF chunks to renegotiate stream state between peers. When the kernel receives a response or a completing request, it stops the reconf timer on the transport the original request was sent over. The completion sites read t = asoc->strreset_chunk->transport and then call timer_delete(&t->reconf_timer).

The chunk->transport field is only populated by __sctp_packet_append_chunk() once the chunk is appended to an outbound packet, and sctp_outq_flush_ctrl() arms the reconf timer at that same moment. A request already stored in asoc->strreset_chunk but not yet transmitted has neither an assigned transport nor an armed timer. Completing such a request dereferences NULL, as reflected in the KASAN report null-ptr-deref in range [0x00000000000001e8-0x00000000000001ef] at timer_delete+0x67/0x110.

Root Cause

The root cause is a missing precondition check on chunk->transport before treating asoc->strreset_chunk as an in-flight request. The completion logic assumes any pending RECONF chunk has been transmitted, but internal state transitions can leave it queued. Two paths reach the bug: sctp_send_asconf_del_ip() sets asoc->src_out_of_asoc_ok when removing the last local address, causing sctp_outq_flush_ctrl() to leave non-ASCONF control chunks queued indefinitely; and sctp_cmd_interpreter() uncorks the outqueue only after processing an entire packet, so a reply generated mid-walk stays untransmitted while further RECONF chunks in the same packet are processed.

Attack Vector

The attack vector is Network (AV:N) with low complexity and no privileges required. A remote peer with an established SCTP association can send a single RECONF chunk carrying an Incoming SSN Reset Request, Outgoing SSN Reset Request, and Response, or two RECONF chunks in one packet, to reach the vulnerable dereference. Locally, an unprivileged process can remove an association's last address and then request a stream reset to trigger the same panic from softirq context.

No public proof-of-concept is listed in the enriched data. Technical details are available in the upstream fix commits (0ee697d, 25419f5, 2db9bfa, 53141db, 6889112, 77ea60f, 79ff751, b2d6d87) on git.kernel.org.

Detection Methods for CVE-2026-89477

Indicators of Compromise

Kernel panic or oops entries referencing timer_delete, sctp_process_strreset_addstrm_out, sctp_process_strreset_outreq, or sctp_process_strreset_resp in the call stack
KASAN reports showing null-ptr-deref within the SCTP RECONF completion path
Unexpected SCTP association resets or host reboots on systems processing SCTP traffic

Detection Strategies

Monitor dmesg and /var/log/kern.log for oops signatures containing sctp_sf_do_reconf and timer_delete frames
Inspect network telemetry for inbound RECONF chunks bundling multiple stream reset parameters or multiple RECONF chunks per packet
Correlate SCTP address deletion (sctp_send_asconf_del_ip) activity with subsequent stream reset requests from the same process

Monitoring Recommendations

Enable kernel crash dump collection (kdump) on SCTP-facing hosts to capture the faulting stack for triage
Ingest kernel logs into a centralized log platform and alert on SCTP-related panic strings
Track kernel version inventory across telecom and clustering workloads to identify unpatched hosts

How to Mitigate CVE-2026-89477

Immediate Actions Required

Apply the upstream kernel patches referenced by commits 0ee697d, 25419f5, 2db9bfa, 53141db, 6889112, 77ea60f, 79ff751, and b2d6d87 from your distribution vendor
Restrict inbound SCTP traffic to trusted peers using host firewall rules where SCTP is not required externally
Audit local SCTP-using processes and revoke unnecessary access on multi-tenant hosts

Patch Information

The fix guards the lookup so that asoc->strreset_chunk is not matched while chunk->transport is NULL, covering all three completion sites. Patches are available in stable kernel trees via the referenced commits, including commit 79ff751 and commit b2d6d87. Consumers should install the vendor-backported kernel update matching their supported branch.

Workarounds

Disable the SCTP module on hosts that do not require it: echo 'install sctp /bin/true' > /etc/modprobe.d/disable-sctp.conf
Block SCTP (IP protocol 132) at the network perimeter and host firewall for endpoints that do not need it
Limit which local users can create SCTP sockets by removing CAP_NET_RAW where feasible and monitoring socket creation

bash

# Blacklist SCTP module and block protocol 132 at the host firewall
echo 'blacklist sctp' | sudo tee /etc/modprobe.d/blacklist-sctp.conf
echo 'install sctp /bin/true' | sudo tee -a /etc/modprobe.d/blacklist-sctp.conf
sudo iptables -A INPUT -p 132 -j DROP
sudo ip6tables -A INPUT -p 132 -j DROP