In the Linux kernel

CVE-2026-52924 is a use-after-free in the Linux kernel's SCTP (Stream Control Transmission Protocol) subsystem. When a remote peer sends a Stale Cookie ERROR during SCTP association setup, the kernel rolls the association back from COOKIE_ECHOED to COOKIE_WAIT. During this rollback, sctp_stream_update() frees the old stream table and installs a new one, but fails to invalidate cached pointers like stream->out_curr. Later dequeue operations (FCFS, RR, PRIO schedulers) dereference the stale pointer, crashing the kernel. Affected: all kernels prior to 7.1-rc7; backport fixes land in 5.10.259, 6.1.176, 6.12.94, and 7.0.13. The SCTP kernel module (sctp.ko) must be loaded for the vulnerability to be reachable.

The NVD vendor score of 9.8 CRITICAL (AV:N/AC:L/PR:N/UI:N) is misleading. Red Hat independently scored this 7.0 HIGH with AC:H and downgraded confidentiality and integrity to Low, reflecting the reality that exploitation requires a specific timing window during the stale cookie rollback sequence *and* that reliable code execution from this UAF is unproven. The primary confirmed impact is a kernel panic — a denial-of-service. The 9.8 assumes trivial exploitation and full CIA impact, which does not match the evidence. Red Hat's 7.0 is closer to reality, and even that may be generous given how rarely SCTP is deployed in enterprise environments.

Why this verdict

• Attack complexity is HIGH, not LOW. Red Hat independently rated AC:H because the stale cookie rollback must race with queued outbound data dequeue — a timing-dependent condition the attacker cannot fully control. The NVD AC:L rating is indefensible for this bug class.
• SCTP module deployment is extremely narrow. In a typical 10,000-host enterprise fleet, fewer than 500 hosts (often zero) will have sctp.ko loaded. The module is not loaded by default on RHEL, Ubuntu, or Debian. This dramatically shrinks the reachable attack surface.
• No PoC, no exploitation, rock-bottom EPSS. EPSS of 0.34% places this in the bottom quartile. Zero public exploit code exists. No threat actor has been observed targeting this bug. The theoretical-to-practical gap is wide.
• Primary confirmed impact is DoS, not RCE. While UAFs *can* lead to code execution, this specific bug's heap layout and timing constraints make reliable exploitation for code execution speculative. Kernel hardening features (KASLR, slab freelist randomization, init-on-free) add further friction.
• Role multiplier: On *telecom infrastructure* (5G core, IMS, Diameter) where SCTP is a core protocol, the blast radius of a kernel crash is service-level DoS affecting mobile subscribers — this is a high-value role and prevents downgrading below HIGH. On standard enterprise servers (web, app, DB tiers), SCTP is absent and the vuln is unreachable. On Kubernetes nodes using SCTP multihoming (rare), a kernel panic could disrupt container workloads but is contained to one node. The telecom use case — where SCTP is canonically deployed and the blast radius is carrier-grade service disruption — sets the floor at HIGH.

Why not higher?

CRITICAL would require either demonstrated code execution (there is none), active exploitation (there is none), or trivial exploitability on a broadly deployed component. SCTP's narrow footprint means the vast majority of Linux hosts are simply not vulnerable. The attack complexity is genuinely high, and the confirmed impact ceiling is DoS, not full system compromise.

Why not lower?

MEDIUM would undercount the risk to the telecom and carrier infrastructure segment where SCTP is a first-class protocol and kernel crashes cause real service outages. The bug *is* network-reachable without authentication, and UAFs in the kernel are inherently dangerous even when current exploitation is unproven — the primitive exists and could be weaponized. Red Hat's 7.0 confirms this belongs in the HIGH bucket.

1. Unload and blacklist the SCTP kernel module on hosts that don't need it — Run modprobe -r sctp and add install sctp /bin/false to /etc/modprobe.d/disable-sctp.conf. This completely eliminates the attack surface. Deploy within 30 days per the noisgate mitigation SLA for HIGH. On hosts that *do* need SCTP, this is not an option — proceed to patching.
2. Block SCTP at the network perimeter — Add firewall rules to drop IP protocol 132 (SCTP) at perimeter firewalls and host-based firewalls (iptables -A INPUT -p sctp -j DROP) for any host not explicitly requiring SCTP. This prevents remote exploitation from untrusted networks. Deploy within 30 days.
3. Prioritize kernel patching on SCTP-enabled hosts — Identify hosts with sctp module loaded (lsmod | grep sctp fleet-wide) and fast-track kernel updates to fixed versions (6.1.176+, 6.12.94+, 7.0.13+). These hosts are your actual risk population. Target 30-day deployment for the mitigation, 180-day full remediation per noisgate SLA.
4. Enable kernel hardening features — Ensure CONFIG_INIT_ON_FREE_DEFAULT_ON=y, KASLR enabled, and CONFIG_SLAB_FREELIST_HARDENED=y in your kernel config. These make UAF exploitation for code execution significantly harder, reducing the risk from DoS-only to even-less-likely-RCE.

Run this script as root on each target Linux host to check whether the SCTP module is loaded and whether the running kernel version is patched. No arguments needed: sudo bash check_cve_2026_52924.sh. Works on RHEL, Debian, Ubuntu, and derivatives.

#!/bin/bash
# check_cve_2026_52924.sh — CVE-2026-52924 SCTP UAF checker
# Run as root on target Linux host
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -euo pipefail

RESULT="UNKNOWN"
SCTP_LOADED=false

# Check if SCTP module is loaded or built-in
if lsmod 2>/dev/null | grep -q '^sctp '; then
  SCTP_LOADED=true
  echo "[!] SCTP module is LOADED — attack surface is present"
elif grep -q 'sctp' /proc/modules 2>/dev/null; then
  SCTP_LOADED=true
  echo "[!] SCTP module is LOADED — attack surface is present"
elif [ -f /boot/config-$(uname -r) ] && grep -q 'CONFIG_IP_SCTP=y' /boot/config-$(uname -r) 2>/dev/null; then
  SCTP_LOADED=true
  echo "[!] SCTP is compiled into the kernel (built-in) — attack surface is present"
else
  echo "[*] SCTP module is NOT loaded and not built-in — attack surface absent"
  echo "PATCHED (not applicable — SCTP not present)"
  exit 0
fi

# Get kernel version
KERNEL=$(uname -r)
echo "[*] Running kernel: $KERNEL"

# Extract version components
MAJOR=$(echo "$KERNEL" | cut -d. -f1)
MINOR=$(echo "$KERNEL" | cut -d. -f2)
PATCH=$(echo "$KERNEL" | sed 's/^[0-9]*\.[0-9]*\.//' | sed 's/[^0-9].*//')

# Check against known fixed versions
# Upstream: 7.1-rc7+
# Debian backports: 5.10.259+, 6.1.176+, 6.12.94+, 7.0.13+

check_fixed() {
  if [ "$MAJOR" -gt 7 ]; then
    return 0 # fixed
  elif [ "$MAJOR" -eq 7 ] && [ "$MINOR" -ge 1 ]; then
    return 0 # 7.1+ fixed
  elif [ "$MAJOR" -eq 7 ] && [ "$MINOR" -eq 0 ] && [ "$PATCH" -ge 13 ]; then
    return 0 # 7.0.13+ fixed
  elif [ "$MAJOR" -eq 6 ] && [ "$MINOR" -eq 12 ] && [ "$PATCH" -ge 94 ]; then
    return 0
  elif [ "$MAJOR" -eq 6 ] && [ "$MINOR" -eq 1 ] && [ "$PATCH" -ge 176 ]; then
    return 0
  elif [ "$MAJOR" -eq 5 ] && [ "$MINOR" -eq 10 ] && [ "$PATCH" -ge 259 ]; then
    return 0
  fi
  return 1
}

if check_fixed; then
  echo "PATCHED — kernel $KERNEL includes the fix for CVE-2026-52924"
  exit 0
else
  if [ "$SCTP_LOADED" = true ]; then
    echo "VULNERABLE — kernel $KERNEL is unpatched AND SCTP is active"
    exit 1
  else
    echo "VULNERABLE — kernel $KERNEL is unpatched (SCTP not loaded, but module could be loaded)"
    exit 1
  fi
fi

Sources

1. Red Hat CVE Page — CVE-2026-52924
2. Debian Security Tracker — CVE-2026-52924
3. Upstream Kernel Fix Commit
4. BitNinja — CVE-2026-52924 Analysis
5. NCA Saudi Arabia — Weekly Vulnerability Summary (June 21-27)
6. HKCERT — Debian Linux Kernel Multiple Vulnerabilities
7. TechVeda — Linux Kernel CVEs to Patch (Jun-Jul 2026)