Mitigating SCTPhantom (CVE-2026-64564) on Rocky Linux 8, 9, 10, and LTS Variants

cve cve-2026-64564 sctphantom security kernel rocky linux lts mitigation sctp

Arsalan Zaidi
Customer Support Engineering Lead

Aug 07, 2026

Introduction

SCTPhantom, tracked as CVE-2026-64564, is a use-after-free vulnerability in the Linux kernel's SCTP (Stream Control Transmission Protocol) implementation. A local unprivileged user can exploit the flaw to escalate privileges to root, with container-to-host escape possible. The vulnerability has a CVSS v4.0 base score of 8.5 (High) and has been present since Linux kernel 2.6.25, introduced in 2007.

The flaw originates in sctp_process_asconf(), which caches a transport pointer when processing ASCONF chunks. A crafted ASCONF sequence can cause an identity mismatch between the packet source address and the ASCONF Address Parameter, allowing an attacker to free the cached transport while the kernel still holds a dangling reference. The resulting use-after-free is deterministic and does not require a race condition.

This article covers Rocky Linux 8, 9, and 10 systems, including CIQ LTS, FIPS, and RLC Pro variants. It describes what the vulnerability affects, the current exposure level, and how to confirm your system is protected.

Problem

SCTPhantom affects systems where the sctp kernel module is loaded and active. On CIQ enterprise products, the sctp module is denylisted by default and cannot be loaded through accidental userspace insertion. Most CIQ systems have never loaded SCTP and are not exposed. The exploit requires local code execution and a loaded SCTP module. Once those conditions are met, the exploit is reliable and can achieve full root access.

SCTP is not commonly used in enterprise Linux environments. It sees use in telecom signaling (SS7/SIGTRAN), some database clustering configurations, and multi-homed transport scenarios. Most enterprise systems have never loaded the module.

The following systems contain the vulnerable kernel code but are not exposed unless an administrator has explicitly loaded the SCTP module:

Rocky Linux 8 and 9 LTS variants
RLC Pro FIPS variants
RLC Pro variants based on Rocky Linux 8, 9, or 10, including RLC Pro Hardened

CIQ Bridge 7.9 does not include the SCTP denylist and should be treated as exposed if the module is loaded. A code fix is in progress.

Status

CIQ enterprise products (RLC Pro, LTS, FIPS, Hardened, SIG/Cloud Next) include a denylist entry for the sctp module. The module cannot be loaded through accidental userspace insertion. Systems that have not explicitly loaded SCTP are not exposed to SCTPhantom. No action is required on these systems unless SCTP was explicitly loaded by an administrator.
CIQ Bridge 7.9: a code fix is in progress and will be included in the next CIQ Bridge 7.9 build. Until the updated build is available, CIQ Bridge 7.9 customers should verify whether SCTP is loaded and apply the mitigation if it is.
Recommended action: verify that the sctp module is not loaded on your systems (see Verification below). If it is loaded and you do not require SCTP for your workload, apply the mitigation. If it is not loaded and the denylist is in place, no action is required.
Patched kernels will be listed in this article as they become available and are tested.

For community Rocky Linux releases, refer to errata.rockylinux.org for patch availability.

Open a support case if you need help assessing SCTP exposure or tracking patched kernel availability for a specific CIQ variant.

Mitigation

Apply the steps in this section only if the sctp kernel module is currently loaded on your system. If the module is not loaded and the denylist is in place, no mitigation is needed.

Check whether SCTP is loaded

lsmod | grep -E '^sctp[[:space:]]'

If this produces no output, the module is not loaded and the system is not currently exposed. Proceed to the Verification section to confirm the denylist is in place.

If the module is loaded, continue with the steps below.

Block the SCTP module

Step 1: install the modprobe override.

sudo sh -c "printf 'install sctp /bin/false\n' > /etc/modprobe.d/block-CVE-2026-64564.conf"

This prevents all future load attempts of the sctp module, including explicit modprobe sctp requests. The install ... /bin/false directive is stronger than the default blacklist entry, which only prevents auto-loading triggered by kernel module aliases.

Step 2: unload the module.

Warning: Unloading the sctp module terminates all active SCTP associations. Applications using SCTP for transport will lose connectivity. Confirm that no production workloads depend on SCTP before proceeding, or schedule a maintenance window.

sudo rmmod sctp

If rmmod fails because the module is in use, identify the SCTP consumers:

ss --sctp -a

Stop the processes holding SCTP associations, then retry rmmod. If stopping the consumers is not feasible, a reboot with the modprobe override in place achieves the same result.

Verification

Confirm the sctp module is not loaded:

lsmod | grep -E '^sctp[[:space:]]'

No output means the module is not currently in memory.

Confirm the denylist or modprobe override is in place. On CIQ enterprise products, the default denylist entry can be verified with:

grep -r "blacklist sctp" /usr/lib/modprobe.d/ /etc/modprobe.d/ 2>/dev/null

If a blacklist sctp entry exists, the module is protected from accidental auto-loading.

If you applied the mitigation from this article, confirm the stronger override is active:

cat /etc/modprobe.d/block-CVE-2026-64564.conf

You should see install sctp /bin/false.

Confirm modprobe respects the override:

sudo modprobe -n -v sctp

This should print install /bin/false. If it resolves to a .ko path instead, the override is not active. Re-check that the conf file exists and is readable, and verify no other modprobe configuration overrides it.

Resolution

Once patched kernels are available and installed, verify the running kernel with:

uname -r

After rebooting with a patched kernel, the modprobe override can be removed if your workload requires SCTP:

sudo rm /etc/modprobe.d/block-CVE-2026-64564.conf
sudo modprobe sctp

Confirm the module loaded:

lsmod | grep -E '^sctp[[:space:]]'

This article will be updated with patched kernel versions as they become available and are tested.

Notes

SCTP is uncommon in enterprise Linux environments. Unless your workload explicitly uses SCTP (telecom signaling, multi-homed transport, certain database clusters), the module is likely not loaded and no action is required.
The default denylist prevents auto-loading, not explicit loading. The blacklist directive in modprobe.d stops the kernel from auto-loading sctp when a process triggers a module alias request. It does not prevent an administrator from running modprobe sctp directly. The install sctp /bin/false override in the mitigation section blocks all loading paths.
IPsec, ESP, and rxrpc are not affected by this CVE. SCTPhantom is in the SCTP subsystem only. The Dirty Frag and Fragnesia mitigations (blocking esp4, esp6, and rxrpc) are unrelated to this vulnerability.
Container environments. The exploit supports container-to-host escape. If the sctp module is loaded on the host kernel, containers running on that host can potentially reach the vulnerable code path.
Public exploit availability. A working exploit chain is publicly documented and has been confirmed across kernel versions 5.14 through 7.2-rc2. Treat systems with the SCTP module loaded as exploitable until the mitigation is applied or a patched kernel is installed.