SCTPhantom — SCTP ASCONF transport use-after-free

This tracker is no longer updated. Every maintained upstream stable line carries the fix, as do Debian, Proxmox VE’s maintained kernels, every tracked NixOS ref, Rocky Linux / RHEL 10, 9 and 8, and all three Amazon Linux 2023 kernel streams. The one remaining gap is Proxmox VE 8’s end-of-life proxmox-kernel-6.14 opt-in, which will never be fixed — upgrade to Proxmox VE 9.

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 mainline in v7.2-rc5 and has been backported to every maintained stable and long-term line.

7.1.x is end of life. It carries the fix but gets no further updates — move to 7.2.x or a long-term line.

Debian

• forky is testing, the future Debian 14.
• bookworm’s opt-in 6.12 kernel is the linux-6.12 package in bookworm-security: trixie’s 6.12 kernel rebuilt for bookworm.

bullseye (Debian 11) left LTS support on 2026-08-31 without the fix. Its 5.10-line default kernel and the withdrawn linux-6.1 opt-in stay vulnerable, and no fix is coming — upgrade to bookworm or newer.

Debian ships SCTP as the sctp module, autoloaded on first use of an SCTP socket and not blacklisted, so any host running an SCTP service loads the vulnerable code.

Proxmox VE

Proxmox ships its own Ubuntu-derived kernels, so Debian’s status does not carry over. The default kernels — PVE 9’s proxmox-kernel-7.0 and PVE 8’s proxmox-kernel-6.8 — carry a cherry-picked fix.

• PVE 8 reached end of life in August 2026. Its 6.8 kernel is fixed for this bug but gets nothing further — upgrade to PVE 9.
• PVE 8’s proxmox-kernel-6.14 opt-in (from bookworm-backports, distinct from PVE 9’s preview series of the same number) stays vulnerable: its Ubuntu base, linux-hwe-6.14, is itself end-of-life, and with PVE 8 past its own end of life no Proxmox fix is expected either. Upgrade to PVE 9.
• Abandoned preview series that Proxmox still publishes — PVE 9’s proxmox-kernel-6.14 and proxmox-kernel-6.17, PVE 8’s proxmox-kernel-6.2 and proxmox-kernel-6.5 — never got the fix. A host booting one should switch to its release’s default kernel.

NixOS

Every tracked ref’s default linuxPackages is linux_6_18, which carries the fix. nixpkgs also pins linux_6_1, linux_5_15 and linux_5_10 at fixed releases, so a host overriding the default is fixed too, as long as it tracks a ref current enough to have picked up that bump.

Kernel updates land on nixpkgs master first and reach each channel once its Hydra jobset passes, so a channel can sit a few days behind master. The -small channels (nixos-unstable-small, nixos-26.05-small) run a reduced jobset and pick up kernel updates fastest.

Which ref a flake input follows:

• github:NixOS/nixpkgs/nixos-unstable follows Unstable — the GitHub channel branches are updated to exactly the published channel pins.
• A bare github:NixOS/nixpkgs with no ref follows master, and github:NixOS/nixpkgs/release-26.05 follows that branch. Both are ungated development branches — they carry a kernel bump as soon as it lands, days before a channel publishes it.
• A bare nixpkgs registry input resolves by default to nixpkgs-unstable (Unstable (nixpkgs)): a separate channel aimed at Nix on other operating systems, not gated on the NixOS tests.

Rocky Linux / RHEL family

All three EL lines — EL10 (6.12-based), EL9 (5.14-based) and EL8 (4.18-based) — carry SCTP and are in-window. Red Hat has shipped fixes for each line’s current minor release and its extended-support streams, and Rocky has rebuilt all three. Rocky 8 and 10 have no RLSA for this CVE, but their shipped kernels’ changelogs name it.

Red Hat advisories by stream:

• RHEL 10: 10.2 RHSA-2026:71233; 10.0 EUS RHSA-2026:69089.
• RHEL 9: 9.8 RHSA-2026:71232; 9.6 EUS RHSA-2026:70484; 9.4 E4S RHSA-2026:69908; 9.2 E4S RHSA-2026:70482 (kernel-rt RHSA-2026:70483).
• RHEL 8: 8.10 RHSA-2026:71213 (kernel-rt RHSA-2026:71016); 8.8 TUS/E4S RHSA-2026:69837; 8.6 EUS/AUS RHSA-2026:69906; 8.4 EUS/AUS RHSA-2026:69874.
• RHEL 7 ELS: RHSA-2026:70290 (kernel-rt RHSA-2026:70308).

On RHEL 9 and 10 the real-time kernel (kernel-rt) is fixed by the same advisories as the regular kernel; RHEL 9.2 E4S, 8 and 7 have separate kernel-rt advisories, listed with the kernel’s.

sctp does not autoload on a stock EL host. On EL8, EL9 and EL10 alike sctp.ko ships only in kernel-modules-extra, which also installs /etc/modprobe.d/sctp-blacklist.conf (blacklist sctp). An explicit modprobe sctp still loads it wherever the package is installed, so this does not stop a local attacker.

AlmaLinux shipped ALSA-2026:71213 (EL8, plus kernel-rt ALSA-2026:71016) and ALSA-2026:71232 (EL9). CloudLinux and Oracle Linux’s Red Hat Compatible Kernel get the fix as they rebuild Red Hat’s advisories.

Amazon Linux

The three AL2023 streams are the default kernel package (6.1 line) and the opt-in kernel6.12 and kernel6.18 packages. The default stream’s fixed build sits below upstream’s 6.1.183 first fix — Amazon backported the fix — so judge an AL2023 kernel by its ALAS, not its version number.

Amazon Linux 2 reached end of support on 2026-06-30. Its 4.14, 5.10 and 5.15 kernels carry SCTP and stay vulnerable, with no fix coming — move to AL2023.

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? These sysctls set only the system-wide default — they decide whether a listening service that relies on that default will process ASCONF from remote peers. A local process enables ADD-IP and AUTH on its own socket (SCTP_ASCONF_SUPPORTED / SCTP_AUTH_SUPPORTED, no privilege) regardless of their value, so a 0 here does not measure local exposure:

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.

Bound the remote surface with the ADD-IP sysctls

These sysctls bound only the remote surface, and only for a service that relies on the system default. Keeping net.sctp.addip_noauth_enable at 0 (its default) makes a remote ASCONF carry a valid AUTH chunk, so a remote peer must complete SCTP-AUTH key negotiation first. Apply it for the current boot:

sudo sysctl -w net.sctp.addip_noauth_enable=0

Persist it across reboots:

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

Where ADD-IP is not needed at all, net.sctp.addip_enable=0 additionally stops a default-configured listener from processing ASCONF from remote peers.

Neither sysctl touches the local vector. The discoverers’ demonstrated privilege escalation and container escape enable ADD-IP and AUTH per socket (SCTP_ASCONF_SUPPORTED / SCTP_AUTH_SUPPORTED, no CAP_NET_ADMIN, working under the default container seccomp profile) and send a legitimately authenticated ASCONF — so a 0 in either sysctl leaves that path fully open. On a multi-tenant or container host, only blocking the sctp module (above) or patching removes it.

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. The ADD-IP sysctls give no protection here: the demonstrated exploit enables ADD-IP and AUTH per socket without CAP_NET_ADMIN and authenticates its own ASCONF, so only blocking the sctp module or patching closes this path.
• No “too old to be affected”: the flaw dates to 2.6.25, so old LTS kernels are not safe by age. Every maintained upstream line now carries the fix, but distro kernels adopt it independently — check the First fixed column for the distro in question, 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