CVE-2026-52917: Linux Kernel Use-After-Free Vulnerability

CVE-2026-52917 Overview

CVE-2026-52917 is a Linux kernel vulnerability in the Stream Control Transmission Protocol (SCTP) sock_diag subsystem. The exact dump_one lookup path can hold a transport reference, block on lock_sock(sk), and resume after sctp_association_free() has already marked the association dead and freed its bind address list. When that happens, inet_assoc_attr_size() and inet_diag_msg_sctpasoc_fill() continue to dereference state that is no longer valid. The flaw can trigger an out-of-bounds read from unrelated association memory when an empty bind-address list is treated as a real sctp_sockaddr_entry. The fix rejects reaped or detached associations after acquiring the socket lock and reports the lookup as stale.

Critical Impact
A local user with diagnostic socket access can trigger an out-of-bounds read of kernel memory through SCTP sock_diag, leading to information disclosure or kernel instability.

Affected Products

Linux kernel with SCTP support compiled in (CONFIG_IP_SCTP)
Linux kernel sock_diag interface (CONFIG_INET_DIAG, CONFIG_INET_SCTP_DIAG)
Distributions shipping affected kernel versions prior to the referenced stable patches

Discovery Timeline

2026-06-24 - CVE-2026-52917 published to NVD
2026-06-24 - Last updated in NVD database

Technical Details for CVE-2026-52917

Vulnerability Analysis

The vulnerability lives in the SCTP diagnostic interface used by tools such as ss to enumerate SCTP associations. The exact-match dump_one path resolves an association, takes a transport reference, and then calls lock_sock() on the owning socket. Because lock_sock() can block, another thread may run sctp_association_free() in the meantime. That teardown marks the association dead, detaches it from the endpoint, and frees the bind address list.

When the diag thread resumes, it proceeds to format reply attributes using inet_assoc_attr_size() and inet_diag_msg_sctpasoc_fill(). Those helpers walk fields that the freed teardown has already invalidated. The bind address list head is empty, but the fill routine still treats the list head as a valid sctp_sockaddr_entry, reading past the head into unrelated kernel memory and producing an out-of-bounds read.

Root Cause

The root cause is a missing liveness check between lock_sock() and attribute formatting in the SCTP diag exact-lookup path. The transport reference keeps the transport pinned, but it does not prevent the association from being reaped concurrently. The code assumed that holding a transport reference and then taking the socket lock was sufficient to guarantee a consistent association, which is not true when the association can be freed while the diag thread sleeps on the lock.

Attack Vector

An unprivileged local process with the ability to open NETLINK_SOCK_DIAG sockets can race SCTP diagnostic queries against association teardown. By repeatedly issuing exact dump_one requests targeting transient SCTP associations while they are closing, an attacker can win the race between lock_sock() blocking and sctp_association_free() completing. Successful exploitation surfaces out-of-bounds kernel memory through netlink replies or causes kernel memory corruption symptoms.

No verified public proof-of-concept is available. The vulnerability mechanism is described in the upstream patches referenced in Kernel Patch 480f754 and Kernel Patch f5af203.

Detection Methods for CVE-2026-52917

Indicators of Compromise

Kernel KASAN or slab-out-of-bounds reports referencing inet_diag_msg_sctpasoc_fill or inet_assoc_attr_size in the call stack.
Unexpected kernel oops or general protection fault traces originating from SCTP sock_diag handling.
Repeated, high-frequency SOCK_DIAG_BY_FAMILY netlink requests from non-administrative processes targeting AF_INET/AF_INET6 with SCTP protocol.

Detection Strategies

Audit kernel logs (dmesg, journalctl -k) for SCTP diag stack traces and memory sanitizer reports.
Correlate netlink socket diagnostic activity with the originating process identity and capability set using auditd rules on socket() and sendmsg().
Track installed kernel versions across fleet inventory and flag hosts running unpatched builds that still expose CONFIG_INET_SCTP_DIAG.

Monitoring Recommendations

Enable kernel address sanitizer (KASAN) builds in lab environments to catch the out-of-bounds read pattern during regression testing.
Monitor netlink usage from non-root processes and alert on unusual volumes of SCTP-related sock_diag queries.
Track concurrent SCTP association close events alongside diag enumeration to surface race-condition exploitation attempts.

How to Mitigate CVE-2026-52917

Immediate Actions Required

Apply the upstream stable kernel patches that reject reaped or detached associations in the SCTP diag exact-lookup path.
Identify hosts that load the sctp module and prioritize patching for systems exposing diagnostic netlink to non-root users.
Restrict NETLINK_SOCK_DIAG access on multi-tenant systems where untrusted local users would otherwise have unconstrained query capability.

Patch Information

Fixes are available in the mainline and stable kernel trees. Apply the relevant commits for your branch: Kernel Patch 480f754, Kernel Patch 5425de8, Kernel Patch 5eba3e4, Kernel Patch 6657af8, Kernel Patch 78c4f96, Kernel Patch b2be72d, Kernel Patch e97c2a5, and Kernel Patch f5af203. Track your distribution security tracker for the corresponding backports.

Workarounds

Unload the sctp module on systems that do not require SCTP: modprobe -r sctp and blocklist it in /etc/modprobe.d/.
Block the SCTP diagnostic family by removing CONFIG_INET_SCTP_DIAG in custom kernel builds where SCTP itself must remain available.
Constrain access to AF_NETLINK/NETLINK_SOCK_DIAG for untrusted users using seccomp, namespaces, or LSM policies until patches are deployed.

bash

# Disable the SCTP module where it is not required
echo 'install sctp /bin/true' | sudo tee /etc/modprobe.d/disable-sctp.conf
sudo modprobe -r sctp 2>/dev/null || true

# Verify the module is not loaded
lsmod | grep -i sctp