CVE-2026-52917

What it actually does

This is a Linux kernel race condition in the SCTP socket diagnostic path. An exact SCTP sock_diag lookup can retain a transport reference, wait on the socket lock, and then continue after the associated SCTP association has already been reaped or detached. In that stale state, diagnostic formatting code can dereference association data that is no longer valid, including a freed or empty bind-address list, potentially causing an out-of-bounds kernel memory read and kernel instability. The issue is local to systems with vulnerable kernel code and SCTP diagnostic access; there is no indication from the provided data of known public exploitation, KEV listing, or ransomware use.

Why it matters to the business

The main operational risk is host instability or exposure of unintended kernel memory through a low-level networking diagnostic interface. On affected Linux systems, a local user or process with sufficient ability to query SCTP socket diagnostics could potentially trigger crashes or read unintended memory, which may affect service availability and confidentiality. The current EPSS score is very low and the issue is not listed in CISA KEV, so it is not presently a high-likelihood internet-scale exploitation concern; however, kernel flaws should still be remediated through normal patch cycles, especially on multi-user servers, container hosts, systems using SCTP, and environments where untrusted local workloads run.

How an attack unfolds

An attacker first needs a foothold or local execution context on a vulnerable Linux system, or another way to issue SCTP sock_diag requests through the kernel diagnostic interface. The attacker attempts to create or interact with SCTP associations while concurrently causing association teardown, racing the exact dump-one diagnostic lookup path against association cleanup. If the timing succeeds, the diagnostic code resumes after acquiring the socket lock and formats SCTP association state that has already become stale. The vulnerable path may then read from an invalid bind-address list or adjacent association memory. Depending on kernel configuration, timing, and memory layout, the observable result may be a kernel warning, out-of-bounds read, information exposure through diagnostic output, or a crash.

How to fix it

Update the Linux kernel to a version that includes the SCTP diagnostic fix that rejects stale associations after taking the socket lock. Because no exact affected product list or fixed package versions were provided, use the kernel advisories and package metadata from the relevant Linux distribution or kernel vendor to identify the corrected build. Prioritize patching systems that enable SCTP, expose multi-user shell access, run untrusted containers, or allow workloads with access to netlink socket diagnostic interfaces. If immediate patching is not possible, reduce exposure by disabling SCTP if it is not required, restricting untrusted local execution, limiting container capabilities and namespace access, and monitoring or controlling access to NETLINK_SOCK_DIAG where feasible. Reboot into the patched kernel after installation; installing kernel packages alone is not sufficient if the running kernel is still vulnerable.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel, not just the installed kernel package, is at or above the vendor-fixed version. Check the active kernel with standard platform tooling such as uname -r and compare it to the distribution advisory for this vulnerability. Validate that systems have rebooted after kernel patching. Where SCTP is not required, confirm the SCTP kernel module is not loaded and cannot be auto-loaded under normal operation. For exposure assessment, inventory systems with SCTP enabled, loaded sctp-related modules, or workloads that use SCTP. If a test environment is available, run vendor-provided or internally developed SCTP diagnostic regression tests to confirm that exact sock_diag lookups against torn-down associations return a stale/failed lookup rather than triggering kernel warnings, crashes, or invalid diagnostic output.

Typical attack path

1. Obtain local code execution or another capability that can issue Linux socket diagnostic netlink requests.
2. Create or target SCTP sockets and associations on the vulnerable host.
3. Trigger SCTP diagnostic exact-association lookups using the sock_diag/inet_diag interface.
4. Concurrently force SCTP association teardown so the diagnostic path holds a stale transport reference while waiting on the socket lock.
5. Win the race so diagnostic formatting code processes a reaped or detached SCTP association.
6. Use the result to attempt kernel memory disclosure, trigger kernel errors, or cause denial of service.

How to detect it

Detection is challenging because successful exploitation may not produce application-level logs and may occur entirely through kernel networking diagnostic interfaces. Review kernel logs, system journals, crash dumps, and endpoint telemetry for kernel warnings or oops messages involving SCTP diagnostic code, sock_diag, inet_diag, stale associations, out-of-bounds reads, general protection faults, KASAN reports, or unexpected reboots. Look for unusual local processes repeatedly opening netlink diagnostic sockets or issuing SCTP association diagnostic queries, especially on systems that do not normally use SCTP. On container hosts, review audit, eBPF, or EDR telemetry for containers or untrusted processes interacting with NETLINK_SOCK_DIAG or loading/using SCTP. If crash dumps are available, inspect stack traces for functions such as inet_diag_msg_sctpasoc_fill, inet_assoc_attr_size, and SCTP association free/teardown paths. Absence of logs does not prove absence of exploitation because an out-of-bounds read may not crash the host.

• inet_diag_msg_sctpasoc_fill
• inet_assoc_attr_size
• sctp_association_free
• sctp_diag
• sock_diag
• NETLINK_SOCK_DIAG
• SOCK_DIAG_BY_FAMILY
• sctp: diag
• KASAN: slab-out-of-bounds
• KASAN: out-of-bounds
• BUG: KASAN
• general protection fault
• kernel BUG
• Oops:
• Call Trace:
• sctp_sockaddr_entry
• lock_sock
• association has been reaped
• stale association

What your security team should do

• Identify Linux systems running kernels that predate the vendor fix, with priority on internet-facing servers, multi-tenant systems, container hosts, and systems using SCTP.
• Patch affected systems through the operating system vendor’s kernel update channel and reboot into the fixed kernel.
• If SCTP is not required, disable or block SCTP module loading as a compensating control until patching is complete.
• Restrict untrusted local workloads from accessing unnecessary networking diagnostics capabilities, especially in containerized environments.
• Review kernel logs and crash telemetry for SCTP diagnostic, sock_diag, inet_diag, out-of-bounds read, or kernel oops indicators since the publication date.
• Track distribution advisories for exact fixed kernel package versions because fixed_versions were not supplied in the input.
• Treat exploitation likelihood as currently low due to low EPSS, no KEV status, and no known exploit maturity, but do not defer kernel patching indefinitely because exploitation would occur below the application layer and may be difficult to detect.