CVE-2026-64564

What it actually does

This is a Linux kernel SCTP use-after-free flaw in ASCONF/ADD-IP handling. A crafted SCTP ASCONF chunk can cause the kernel to remove the same transport object that the ASCONF processing path continues to reference. Subsequent DEL-IP processing can dereference freed memory and leave the SCTP association pointing to invalid transport structures. The most likely impact is kernel memory corruption leading to a kernel panic or denial of service; depending on kernel build, allocator behavior, hardening, and attacker control over memory reuse, use-after-free bugs in kernel networking code can potentially become more severe.

Why it matters to the business

Systems that expose SCTP services could be remotely crashed by a malicious peer, causing service interruption, failover events, dropped network sessions, or broader host instability. Risk is lower than many internet-facing TCP/HTTP issues because SCTP is less commonly exposed, EPSS is low, it is not in CISA KEV, and there is no reported public exploit maturity, but organizations using SCTP for telecom, signaling, high-availability, or specialized network services should treat this as operationally important.

How an attack unfolds

An attacker first needs network access to an SCTP endpoint that supports dynamic address reconfiguration using ASCONF/ADD-IP behavior. After establishing or interacting with an SCTP association, the attacker sends a specially ordered ASCONF sequence containing an Address Parameter for an address different from the packet source, followed by a DEL-IP for that address and then a wildcard DEL-IP such as 0.0.0.0. The first DEL-IP can remove the transport object still cached by ASCONF processing. The later wildcard operation then reuses the dangling transport pointer, causing freed kernel memory to be dereferenced and corrupting the association's primary or active path state. Successful exploitation is expected to produce kernel instability, SCTP association corruption, or a host crash.

How to fix it

Upgrade to a Linux kernel version that includes the SCTP fix rejecting DEL-IP operations targeting the transport currently being used for ASCONF processing. If using distribution kernels, apply the relevant vendor security update rather than relying only on upstream version numbers, because fixes may be backported. Where immediate patching is not possible, reduce exposure by disabling SCTP if unused, preventing the SCTP kernel module from loading, blocking SCTP protocol traffic at host and network firewalls, and restricting SCTP access to trusted peers only. For systems that require SCTP, consider disabling or limiting dynamic address reconfiguration features where supported and monitor closely until patched.

How to confirm the fix worked

Confirm the running kernel includes the vendor or upstream fix for SCTP ASCONF DEL-IP handling. Verify the active booted kernel, not only the installed package inventory. Check whether SCTP is enabled or loaded using kernel configuration, loaded modules, open SCTP sockets, and firewall policy. Validate that perimeter and host firewalls block untrusted SCTP traffic where SCTP is not required. In lab or staging only, use SCTP-focused test tooling to confirm malformed ASCONF/DEL-IP sequences no longer crash the host or produce kernel warnings. Review vendor advisories for exact fixed package versions because no product-specific fixed versions were provided in the input.

Typical attack path

1. Identify a reachable Linux host with SCTP enabled and an SCTP service exposed.
2. Establish or reach an SCTP association where ASCONF/ADD-IP processing is accepted.
3. Send a crafted ASCONF chunk containing an Address Parameter for a non-source address.
4. Include a DEL-IP operation for that address to remove the cached transport object.
5. Follow it in the same ASCONF flow with a wildcard DEL-IP, such as 0.0.0.0, to trigger reuse of the freed transport pointer.
6. Cause kernel memory corruption, SCTP association failure, kernel warning/oops, or system crash.

How to detect it

Look for evidence of attempted or successful SCTP ASCONF abuse in packet captures, network telemetry, kernel logs, crash dumps, and EDR telemetry. Network indicators include SCTP traffic containing ASCONF chunks with DEL-IP parameters, especially a sequence where an Address Parameter is followed by DEL-IP for that address and then DEL-IP for 0.0.0.0. Host indicators include kernel oops, panic, KASAN, slab, RCU, or general protection fault messages referencing SCTP ASCONF functions such as sctp_process_asconf, sctp_process_asconf_param, sctp_assoc_rm_peer, sctp_assoc_set_primary, or sctp_assoc_del_nonprimary_peers. Because exploitation may result primarily in a crash rather than persistent artifacts, correlate unexpected reboots or kernel panics with preceding SCTP traffic from untrusted or unusual peers. There are no named threat actors or KEV exploitation reports in the provided data, so detection should focus on protocol-level anomalies and kernel crash artifacts rather than campaign-specific indicators.

• sctp_process_asconf
• sctp_process_asconf_param
• sctp_assoc_rm_peer
• sctp_assoc_set_primary
• sctp_assoc_del_nonprimary_peers
• SCTP_ERROR_DEL_SRC_IP
• KASAN: use-after-free
• BUG: KASAN
• general protection fault
• kernel panic
• Oops:
• ASCONF
• DEL-IP
• DEL-IP 0.0.0.0
• SCTP ASCONF

What your security team should do

• Inventory Linux systems that have SCTP enabled, SCTP kernel modules loaded, or SCTP services exposed.
• Prioritize patching SCTP-exposed systems, telecom/signaling infrastructure, high-availability clusters, and internet- or partner-facing hosts.
• Apply the relevant Linux distribution kernel security update and reboot into the fixed kernel.
• If SCTP is not required, disable SCTP support and block SCTP protocol traffic at network and host firewalls.
• If SCTP is required, restrict access to trusted peers and monitor SCTP ASCONF/ADD-IP activity until all systems are patched.
• Search kernel logs and crash telemetry for SCTP-related oops, KASAN use-after-free reports, or crashes involving ASCONF and DEL-IP handling.
• Track vendor advisories for backported fixed kernel versions and update vulnerability management checks accordingly.