SCTPhantom — SCTP ASCONF transport use-after-free

Summary

ℹ️ Two vantage points, one bug. The kernel CNA scores SCTPhantom as network-reachable (AV:N): a remote peer that completes an SCTP association with ADD-IP negotiated sends the crafted ASCONF, and nothing on the target needs local access. The discoverers score it locally (AV:L) because what they demonstrated is a privilege-escalation and container-escape primitive built on the same use-after-free. Both are correct at different layers — the trigger is a received packet; the weaponised impact shown is local root. Treat any host that terminates untrusted SCTP associations as remotely reachable, and any multi-tenant host as exposed to local escalation.

How the exploitation chain works

SCTP is multi-homed: one association can span several peer IP addresses, each represented by an sctp_transport. The ADD-IP extension (RFC 5061) lets a peer add and remove those addresses at runtime by sending ASCONF chunks, processed in the receive path by sctp_process_asconf().

sctp_process_asconf() caches the transport the chunk arrived on in asconf->transport (set once in sctp_rcv()). When an ASCONF is instead located through its Address Parameter by __sctp_rcv_asconf_lookup(), that cached transport corresponds to the Address Parameter, which need not be the packet’s source address.

sctp_process_asconf_param() already refuses a DEL-IP aimed at the packet source address (the ADD-IP D8 rule, SCTP_ERROR_DEL_SRC_IP) — but nothing protected asconf->transport itself. A single ASCONF can carry, in order:

[Address Parameter L]  [DEL-IP L]  [DEL-IP 0.0.0.0]

where L differs from the source address:

1. [Address Parameter L] selects transport L as asconf->transport.
2. [DEL-IP L] passes the D8 source-address check (the source isn’t L) and calls sctp_assoc_rm_peer() on transport L — the very transport asconf->transport still points at — freeing it (RCU-deferred).
3. [DEL-IP 0.0.0.0] (wildcard) then reuses the now-dangling asconf->transport: sctp_assoc_set_primary() dereferences the freed object (->ipaddr, ->state) and plants the dangling pointer into asoc->peer.primary_path / active_path, while sctp_assoc_del_nonprimary_peers() removes every real transport, keeping only the pointer that is no longer on the list. The association is left with transport_count == 0 and primary_path / active_path pointing at freed memory.

From there the freed sctp_transport is a classic reclaim-and-reuse primitive: a following dereference of the dangling primary_path faults (the oops/panic path), or, with heap grooming, the freed slot is reclaimed by attacker-controlled data for a read/write primitive — which the write-up escalates to root and out of a container.

The fix, 9b2854f86f0b, rejects a DEL-IP that targets the transport the ASCONF is being processed against, mirroring the existing source-address guard, so the wildcard branch can never reuse a freed transport.

⚠️ Because the introducing commit landed in v2.6.25 (2008), this is not a recent-regression bug: there is no “too old to be affected” kernel. Any kernel with SCTP ADD-IP support, from 2.6.25 up to the fixed point releases below, is in-window. A kernel is safe only by carrying the 9b2854f86f0b fix — not by being old.

Vulnerable commit range

The reachable lifetime runs from v2.6.25 through v7.1 (and 7.2 before -rc5). Unlike a backported-regression CVE, no in-support kernel predates the flaw, so the only not-affected kernels are those that carry the fix.

Patch status

A row is Fixed only if its kernel carries the 9b2854f86f0b backport; every SCTP-capable kernel without it is in-window and Vulnerable. The first group is the upstream kernel; the rest are a focused set of x86-64 distributions, with per-distribution detail in the sections that follow. First fixed and Fixed since stay — until a row is fixed.

Linux kernel

The fix reached Linus in v7.2-rc5 (tagged 2026-07-26) and the kernel CNA backported it across the maintained stable lines on 2026-08-03: 6.6.148 (fedeb4468987), 6.12.101 (74e8f3e7114f), 6.18.42 (85aca407c560), and 7.1.6 (d136b29bf91d) — each the same fix by subject, confirmed present on its linux-*.y branch, with finger_banner current point releases at or above them.

The 6.1, 5.15, and 5.10 long-term lines are the exposure. The fix is not present on linux-6.1.y, linux-5.15.y, or linux-5.10.y, and because the bug dates to 2.6.25 all three are fully in-window: a host on 6.1.182, 5.15.215, or 5.10.264 is vulnerable and stays so until its branch picks up the backport, most likely in a later stable release batch.

Debian

Debian’s status splits on which upstream branch each suite tracks. trixie (Debian 13) ships 6.12.101-1, which is exactly the 6.12 branch’s first-fixed release, so it is fixed; sid at 7.1.7-1 (above the 7.1 branch’s 7.1.6 first-fixed) is fixed too. bookworm (6.1.180-1) rides the 6.1 line and bullseye (5.10.262-1) the 5.10 line — neither branch has the backport yet, so both are vulnerable, as the Debian security tracker records. When the 6.1.y and 5.10.y stable lines gain the fix (or Debian cherry-picks it), bookworm and bullseye follow.

Both older suites also offer an opt-in newer kernel, and both are vulnerable here too. bookworm’s linux-6.12 (bookworm-security, 6.12.100-1~deb12u1) sits one point release below the 6.12 branch’s 6.12.101 first fix — the same package cleared earlier 6.12 CVEs but not this one — and bullseye’s linux-6.1 (bullseye-security, 6.1.180-1~deb11u1) rides the still-unpatched 6.1 line.

SCTP itself is not built into Debian’s kernel image but shipped as the sctp module, autoloaded on first use of an AF_INET/IPPROTO_SCTP socket; it is not blacklisted by default, so a host running any SCTP service loads the vulnerable code.

Proxmox VE

Proxmox ships its own kernels, so Debian’s status does not carry over. Both maintained series backport the SCTP fix (a …-sctp-don-t-free-the-ASCONF-s-own-transport-in-DEL-IP.patch): PVE 9’s proxmox-kernel-7.0 first carries it in 7.0.14-10 (2026-08-06), and PVE 8’s proxmox-kernel-6.8 in 6.8.12-41 (2026-08-07). The 6.8 series is the familiar Proxmox pattern: although the upstream 6.8 base is old, the Ubuntu-derived kernel carries SCTP and receives the cherry-pick, so a pre-fix Proxmox series cannot be assumed safe by base version alone.

NixOS

Every tracked ref’s default linuxPackages is linux_6_18, at or above the 6.18 branch’s 6.18.42 first-fixed release, so every tracked ref is fixed; they differ only in which point release each has reached. Kernel updates land on nixpkgs master first, and each channel publishes them once its Hydra jobset passes. A channel can therefore sit a few days behind master, and an unstable channel is not necessarily ahead of a release channel. The -small channels (nixos-unstable-small, nixos-26.05-small) are gated on a reduced jobset and pick up kernel updates fastest. A host that overrides the default to an unpatched series (linux_6_1 / linux_5_15 / linux_5_10) is still vulnerable.

The master and release-26.05 rows are the git branches the fix lands on. They are not Hydra-gated, so they carry a kernel bump from the moment the commit lands — typically a day or more before a channel republishes it, which is what the Fixed since dates down the group show. They are development branches, not deployment targets.

Flake inputs map onto these directly. github:NixOS/nixpkgs/nixos-unstable tracks the nixos-unstable channel — the GitHub channel branches are updated to exactly the published channel pins — and a bare github:NixOS/nixpkgs with no ref follows master. A bare nixpkgs registry input resolves by default to nixpkgs-unstable, which is a separate channel aimed at Nix users on other operating systems rather than at NixOS, so it is not gated on the NixOS tests and can hold a different kernel from nixos-unstable.

Rocky Linux / RHEL family

RHEL-family kernels are long-lived forks that carry SCTP, so all three in-support lines — EL10 (6.12-based), EL9 (5.14-based), EL8 (4.18-based) — are in-window. Red Hat has not published a CVE page or RHSA for CVE-2026-64564 yet (the security page 404s four days after disclosure), so every stream is vulnerable pending an advisory. Default module posture is uniform across the family: on all three releases sctp.ko is not in the base kernel packages but in kernel-modules-extra, and that package installs /etc/modprobe.d/sctp-blacklist.conf (blacklist sctp, plus sctp_diag) alongside it. So sctp never autoloads on a stock EL host — without kernel-modules-extra the module is absent entirely, and with it the blacklist suppresses autoload — though an explicit modprobe sctp still loads it wherever the package is installed, so this does not close the local vector. Rocky rebuilds RHEL’s kernels unchanged, so its fixes track Red Hat’s; AlmaLinux is typically the fastest rebuild and the leading indicator. Oracle Linux and CloudLinux track the RHEL determination.

Amazon Linux

No ALAS has been issued for this CVE, so every AL2023 kernel stream — the default kernel (6.1.177-224.371), the kernel6.12 (6.12.95-124.187) and kernel6.18 (6.18.39-79.141) opt-ins — remains vulnerable pending an Amazon cherry-pick. All three lines are in-window; the 6.12 and 6.18 opt-ins turn fixed only once they cross their branches’ 6.12.101 / 6.18.42 first-fixed releases, and the 6.1 default only when the 6.1.y line itself is patched.

Detection

Is the running kernel in the affected window and missing the fix? Every SCTP-capable kernel is in-window; compare the running kernel against the Patch status table’s First fixed column for its series:

uname -r

Is the sctp module available or loaded? The bug is only reachable when SCTP is in use. On most distributions sctp autoloads on first use of an SCTP socket:

lsmod | grep '^sctp'

Is SCTP autoload blocked? A blacklist/install … /bin/false entry (on Rocky/RHEL 8, 9, and 10 the kernel-modules-extra package that provides sctp.ko ships one) means the datapath will not autoload — though an explicit modprobe sctp still can:

modprobe -n -v sctp 2>&1; grep -rE '(^|[[:space:]])(install|blacklist)[[:space:]]+sctp' /etc/modprobe.d /usr/lib/modprobe.d 2>/dev/null

Is a service actually terminating SCTP associations? Reaching the ASCONF path needs an established association, so an SCTP listener is the real exposure (telephony/SIGTRAN, some RADIUS/Diameter and load-balancer stacks, lksctp test tools):

ss -a --sctp 2>/dev/null || ss -a | grep -i sctp

Is ASCONF (ADD-IP) enabled? The chunk path is gated by the ADD-IP sysctls; addip_noauth_enable=1 additionally drops the AUTH requirement, widening who can send the ASCONF:

sysctl net.sctp.addip_enable net.sctp.addip_noauth_enable

Public PoC

There is no public exploit. The write-up from Tencent Zhuque Lab describes the primitive and reports internal proof-of-concept exploits for local privilege escalation and container-to-host escape, but does not release code. Absence of a public PoC is not safety — the mechanism is fully described and the fix is public, so a working exploit is well within reach; patch rather than rely on obscurity.

Mitigation

The real fix is a patched kernel (the 9b2854f86f0b backport). Until one is installed, the exposure is narrowed by keeping the SCTP datapath unreachable — none of these is a fix.

Disable the sctp module (if you don’t use SCTP)

Most hosts never use SCTP. Where it is genuinely unused, block the module so the vulnerable code cannot be autoloaded — this also blocks privileged and container callers, unlike the sysctl below. Unload it if present but idle:

sudo modprobe -r sctp

Then keep it from being (re)loaded, including on-demand autoload; install sctp /bin/false is surer than a plain blacklist sctp, which only suppresses alias-based autoloading:

echo 'install sctp /bin/false' | sudo tee /etc/modprobe.d/sctphantom.conf

Only do this where SCTP is genuinely unused — telephony/SIGTRAN gateways, some Diameter/RADIUS and SS7 stacks, and lksctp-based tooling need it and must fall back to the measures below.

Require AUTH for ASCONF (do not run addip_noauth)

If SCTP with ADD-IP is required, make sure net.sctp.addip_noauth_enable is 0 (the default) so an ASCONF must carry a valid AUTH chunk, forcing an attacker to complete SCTP-AUTH key negotiation before reaching the handler:

sudo sysctl -w net.sctp.addip_noauth_enable=0
echo 'net.sctp.addip_noauth_enable = 0' | sudo tee /etc/sysctl.d/99-sctphantom.conf

This does not close the bug for a peer that completes AUTH, and it does nothing where ADD-IP is not needed at all — there, disable ADD-IP entirely with net.sctp.addip_enable=0.

Restrict who can reach the SCTP listener

Where the service must stay up, limit exposure at the network edge: firewall SCTP (-p sctp) to known peers, terminate associations only from trusted networks, and avoid exposing SCTP listeners to untrusted clients. This shrinks the remote attack surface but leaves a trusted-peer or local path open.

Risk notes

• SCTP services are the remote surface: any host terminating SCTP associations with ADD-IP negotiated — telephony/SIGTRAN, some Diameter, RADIUS, and SS7 stacks — can be driven into the UAF by a peer. Treat untrusted-peer SCTP as remotely exploitable.
• Multi-tenant and container hosts: the demonstrated impact is local privilege escalation and container-to-host escape, so shared hosts where an unprivileged user or a container can open SCTP sockets are directly in scope — even without a remote peer.
• No “too old to be affected”: the flaw dates to 2.6.25, so old LTS kernels are not safe by age. The 6.1, 5.15, and 5.10 lines are currently unpatched and vulnerable; check the First fixed column, not the kernel’s age.
• sctp often not loaded: on hosts that never use SCTP the module is absent, and blocking its autoload removes reachability entirely — the cheapest durable mitigation short of the patch.

Verification log

Every verdict in the table above is backed by a checkable source. This log records the provenance — the git reference, advisory, or repository index that established each fact — so any row can be audited or reproduced. Most readers never need it.

References