In the Linux kernel

CVE-2026-64564 is a use-after-free vulnerability in the Linux kernel's SCTP (Stream Control Transmission Protocol) ASCONF chunk processor. The function sctp_process_asconf() caches the current transport pointer in asconf->transport. An attacker can craft a malicious ASCONF block that specifies an Address Parameter pointing to address L, then issues a DEL-IP for L (which passes the RFC 5061 D8 source-address protection check because L is *not* the packet's source address), followed by a wildcard DEL-IP (0.0.0.0). The first DEL-IP calls sctp_assoc_rm_peer() which frees the transport cached in asconf->transport, leaving a dangling pointer. Subsequent ASCONF parameter processing dereferences freed memory, planting dangling pointers into asoc->peer.primary_path and active_path. The bug affects any kernel with CONFIG_IP_SCTP compiled in or loaded as a module. The fix landed in the net-next tree (commit 9b2854f) on approximately 2026-08-04 and is pending stable backports.

There is no vendor CVSS score for this CVE yet — NVD has not scored it as of 2026-08-07. The use-after-free primitive is genuinely dangerous: kernel UAFs in network protocol handlers have historically been weaponizable for remote code execution or at minimum denial of service via kernel panic. However, the severity is fundamentally gated by the fact that SCTP is blacklisted by default on RHEL, RHCOS, and most hardened enterprise distributions. The module must be explicitly loaded, and an active SCTP association must exist for the attacker to deliver the crafted ASCONF chunk. For the vast majority of enterprise fleets, this vulnerability has zero exposure.

Why this verdict

• Attack surface gating: SCTP is blacklisted by default on RHEL 8+, RHCOS, and CIS-benchmarked systems. The kernel module must be explicitly loaded and an active SCTP association must exist. This eliminates >95% of a typical enterprise fleet from exposure.
• No exploitation evidence: EPSS is 0.00157, no KEV listing, no public PoC, no known campaigns. The vulnerability was disclosed 3 days ago with the fix, limiting attacker lead time.
• Exploitation complexity: Even when SCTP is active, the attacker needs knowledge of association state (VTAG, secondary bound addresses) and must negotiate ASCONF capability. Kernel heap grooming for RCE adds further complexity beyond the trivial DoS/panic outcome.
• Role multiplier: (a) *Low-value role (workstations, dev machines):* SCTP never loaded — not affected. (b) *Typical role (app servers, web servers):* SCTP not loaded — not affected. (c) *High-value role (telecom core, Diameter nodes, some k8s bare-metal with SCTP CNI):* Chain succeeds, blast radius is host-level DoS or potential host compromise. However, this high-value role represents well under 1% of the general Linux installed base. Telecom-specific fleets where SCTP is canonical should treat this as HIGH.
• Network friction: Perimeter firewalls and cloud security groups almost never permit IP protocol 132 (SCTP) inbound. Even where SCTP is used internally, it is typically isolated to dedicated telecom network segments.

Why not higher?

Elevating to HIGH would require either (a) active exploitation / KEV listing, (b) a public PoC lowering the exploitation bar, or (c) evidence that ≥1% of the general enterprise Linux installed base runs active SCTP associations. None of these conditions are met. The high-value role (telecom infrastructure) where the chain succeeds represents a specialized vertical, not a general enterprise deployment pattern. SCTP's default-blacklisted status on major enterprise distros is a hard architectural gate.

Why not lower?

Dropping to LOW or IGNORE would understate the technical severity of a remotely-triggerable use-after-free in a kernel network protocol handler. Where SCTP IS active (telecom, some k8s), the bug is trivially reachable with a crafted packet and results in at minimum a kernel panic. The fix is not yet in any stable kernel release or distro package, so affected hosts have no patch available. The 3-day-old disclosure means the window is still open for PoC development.

1. Blacklist the SCTP kernel module on all non-telecom hosts — Add install sctp /bin/false and blacklist sctp to /etc/modprobe.d/sctp-blacklist.conf. This is already the RHEL 8+ default and CIS benchmark recommendation. Confirm and enforce across your fleet within the noisgate MEDIUM remediation window (365 days), though given this is a one-line config change, there's no reason not to do it this week.
2. Audit which hosts have SCTP loaded — Run lsmod | grep sctp and check /proc/net/sctp/assocs across your fleet. Any host with active SCTP associations is in the blast radius. Prioritize patching those hosts once stable backports ship.
3. Block SCTP at network boundaries — Ensure firewalls and security groups drop IP protocol 132 (SCTP) at perimeter and inter-zone boundaries. This prevents external exploitation entirely. Most enterprise firewalls already do this by default since they only permit TCP/UDP/ICMP.
4. For telecom hosts: disable ASCONF capability if operationally feasible — If your SCTP applications don't require dynamic address reconfiguration, disable ASCONF negotiation at the application layer. This prevents the ASCONF chunk processing path from being reached. Consult your application vendor (e.g., Diameter, SS7 stack) for configuration guidance.

Run this script on each target host as root (or via your fleet management tool). It checks whether the SCTP module is loaded and whether active SCTP associations exist. Example: sudo bash check_cve_2026_64564.sh

#!/bin/bash
# check_cve_2026_64564.sh — Check exposure to CVE-2026-64564
# SCTP ASCONF DEL-IP use-after-free
# Run as root on target Linux hosts.
# Exit codes: 0=VULNERABLE, 1=PATCHED, 2=UNKNOWN

set -euo pipefail

RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[0;33m'
NC='\033[0m'

# Check if SCTP module is loaded or compiled-in
SCTP_LOADED=0
if lsmod 2>/dev/null | grep -q '^sctp '; then
    SCTP_LOADED=1
elif [ -f /proc/net/sctp/assocs ] 2>/dev/null; then
    SCTP_LOADED=1
elif grep -q 'CONFIG_IP_SCTP=y' /boot/config-$(uname -r) 2>/dev/null; then
    SCTP_LOADED=1
fi

if [ "$SCTP_LOADED" -eq 0 ]; then
    echo -e "${GREEN}PATCHED${NC} (not affected) — SCTP module is not loaded and not compiled-in."
    echo "CVE-2026-64564 requires SCTP to be active. This host has no exposure."
    exit 1
fi

# SCTP is loaded — check for active associations
ACTIVE_ASSOCS=0
if [ -f /proc/net/sctp/assocs ]; then
    # First line is header, count data lines
    ASSOC_COUNT=$(tail -n +2 /proc/net/sctp/assocs 2>/dev/null | wc -l)
    if [ "$ASSOC_COUNT" -gt 0 ]; then
        ACTIVE_ASSOCS=1
    fi
fi

# Check kernel version for fix (placeholder — stable backport versions TBD)
KERNEL=$(uname -r)
echo "Kernel: $KERNEL"
echo "SCTP module: loaded/compiled-in"

if [ "$ACTIVE_ASSOCS" -eq 1 ]; then
    echo -e "${RED}VULNERABLE${NC} — SCTP is loaded with $ASSOC_COUNT active association(s)."
    echo "This host is exposed to CVE-2026-64564 until a patched kernel is installed."
    echo "Active associations:"
    cat /proc/net/sctp/assocs 2>/dev/null
    exit 0
else
    echo -e "${YELLOW}UNKNOWN${NC} — SCTP module is loaded but no active associations found."
    echo "Host is potentially vulnerable if SCTP associations are established later."
    echo "Recommend blacklisting SCTP module if not needed: echo 'install sctp /bin/false' > /etc/modprobe.d/sctp-blacklist.conf"
    exit 2
fi

Sources

1. openKylin Security Advisory — CVE-2026-64564
2. Red Hat — How to setup SCTP in RHEL 8+
3. Linux Kernel SCTP Documentation
4. Linux kernel net-next repository (fix location)
5. CVE-2021-23133 — Prior SCTP UAF privilege escalation (historical reference)
6. OpenShift — Using SCTP on bare metal clusters
7. NIST NVD Dashboard