DiagSpill — SCTP sock_diag transport-count overflow

This tracker is no longer updated. Every maintained upstream stable line carries the fix, as do Debian, Proxmox VE, every tracked NixOS ref, Rocky Linux / RHEL 10, 9 and 8, and all three Amazon Linux 2023 kernel streams — install a fixed kernel and reboot into it.

Summary

ℹ️ The gate is module availability, not privilege. DiagSpill is the outlier of the four bugs disclosed alongside it: the other three (DirtyAH6, TUNderflow, PPPoEject) need unprivileged user namespaces or specific capabilities, so disabling unprivileged user namespaces blunts them. DiagSpill needs neither — an ordinary local account reaches it as long as sctp and sctp_diag can load, so a user namespace lockdown does nothing here. The only thing that flips a row is the kernel backport; the only durable mitigation short of patching is to keep the SCTP modules from loading.

How the exploitation chain works

SCTP is multi-homed: one association can span many peer IP addresses, each represented by an sctp_transport. sctp_assoc_add_peer() adds a new transport for every unique peer address and increments the association’s transport_count — a 16-bit field (__u16). An attacker who controls the association can add unique peer addresses at will, through connectx(), repeated ASCONF ADD-IP chunks, or INIT address parameters. Adding the 65,536th transport wraps transport_count to zero while transport_addr_list still holds every entry.

sctp_diag reports SCTP sockets and their peers over NETLINK_SOCK_DIAG (the interface ss and other tools use). To build the reply it reserves an INET_DIAG_PEERS payload sized from transport_count, then walks transport_addr_list copying one sockaddr_storage for every transport:

1. The count is read as zero, so inet_diag_msg_sctpaddrs_fill() reserves no space in the Netlink skb for the peer payload.
2. The copy loop still iterates all 65,536 transports, writing one sockaddr_storage each — about 8 MiB — straight past the skb tail, over whatever kernel heap follows the buffer.

That overwrite is the primitive. A subsequent access to a corrupted allocation faults (the oops/panic path), or — with heap grooming — the spill lands on attacker-influenced objects for a read/write primitive. The PoC grooms the overwrite into page tables, turns corrupted PMD entries into user-readable/writable mappings of physical RAM, scans them for a helper process’s credentials, zeroes its UID/GID, and uses it to install a temporary sudoers rule and open a root shell.

The fix, bd0e9289e264, rejects a new unique peer once transport_count has reached U16_MAX, so the count can never wrap. The check sits after the existing-peer lookup, so a duplicate address still returns its existing transport at the limit.

⚠️ This is not a recent-regression bug. The reachable defect dates to v4.7 (2016), when the sctp_diag module first exposed the peer list; the transport_count field has been 16-bit far longer. There is no “too old to be affected” kernel — a kernel is safe only by carrying the bd0e9289e264 fix, never by being old. Every tracked distro kernel, EL8’s 4.18 included, is in-window.

Vulnerable commit range

The reachable lifetime runs from v4.7 through v7.1 (and 7.2 before -rc6). DiagSpill is one of a quartet of local-root bugs the same researcher disclosed on 2026-09-18; the siblings are tracked separately at DirtyAH6, TUNderflow, and PPPoEject.

Patch status

A row is Fixed only if its kernel carries the bd0e9289e264 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. Current kernel is the package or point release current when this tracker was retired; First fixed and Fixed since record the first build carrying the fix and the date it shipped.

Linux kernel

The fix reached mainline in v7.2-rc6 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.

To confirm a fix in a tree directly, the change is three lines in sctp_assoc_add_peer() (net/sctp/associola.c): a if (asoc->peer.transport_count == U16_MAX) return NULL; guard added before sctp_transport_new().

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. No further update is coming — upgrade to bookworm or newer.

SCTP ships 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. sctp_diag autoloads the same way when a diagnostic query runs.

Proxmox VE

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

• 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) never got the fix, and its Ubuntu base, linux-hwe-6.14, is itself end-of-life. No fix is coming — upgrade to PVE 9.
• Abandoned preview series that PVE 9 still publishes, proxmox-kernel-6.14 and proxmox-kernel-6.17, never got the fix. A host booting one should switch to the default kernel.

NixOS

Every NixOS channel and branch in the table defaults to linux_6_18 (linuxPackages), which carries the fix. nixpkgs also pins linux_6_12, linux_6_6, 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 current-enough ref.

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 and github:NixOS/nixpkgs/nixos-26.05 follow those channels — 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, often a day or more before a channel publishes it.
• A bare nixpkgs registry input resolves by default to the nixpkgs-unstable channel: a separate channel aimed at Nix on other operating systems, not gated on the NixOS tests.

Rocky Linux / RHEL family

RHEL-family kernels are long-lived forks that carry SCTP, so all three EL lines — EL10 (6.12-based), EL9 (5.14-based) and EL8 (4.18-based) — are in-window. Rocky rebuilds RHEL’s current minor-release kernel.

Red Hat fixed the current minor releases and its extended-support streams in one batch of advisories on 2026-09-24:

• RHEL 10: 10.2 RHSA-2026:71233; 10.0 EUS RHSA-2026:71599.
• RHEL 9: 9.8 RHSA-2026:71232; 9.6 EUS RHSA-2026:71631; 9.4 E4S RHSA-2026:71569; 9.2 E4S RHSA-2026:71601 (kernel-rt RHSA-2026:71606).
• RHEL 8: 8.10 RHSA-2026:71213; 8.8 TUS/E4S RHSA-2026:71594; 8.6 AUS/EUS RHSA-2026:71592; 8.4 AUS/E4S RHSA-2026:71565.
• RHEL 7 ELS: RHSA-2026:71687 (kernel-rt RHSA-2026:71657).

On RHEL 9 and 10 the real-time kernel ships in the same advisory as kernel. The RHEL 8 real-time kernel (kernel-rt) had no fix when this tracker was retired; on a host running it, check Red Hat’s advisories for a fixed kernel-rt build before considering it safe.

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

AlmaLinux, CloudLinux and Oracle Linux’s Red Hat Compatible Kernel rebuild RHEL’s kernel, so they 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.

Amazon Linux 2 reached end of support on 2026-06-30 and gets no further core-package security updates — migrate 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 loaded or available? The bug needs SCTP in use. On most distributions sctp autoloads on first use of an SCTP socket:

lsmod | grep -E '^sctp'

Can the SCTP and diagnostic modules autoload? Both sctp and sctp_diag must be loadable to reach the bug. A dry-run resolve shows what modprobe would do:

modprobe -n -v sctp sctp_diag

An install … /bin/false or blacklist entry blocks autoload (Rocky/RHEL ship one for sctp via kernel-modules-extra), though an explicit modprobe still loads it:

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

Is anything issuing SCTP diagnostic dumps? The overwrite fires when a SOCK_DIAG query walks the peer list, which also autoloads sctp_diag. ss --sctp is the common trigger:

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

Public PoC

The upstream PoC is in manizada/DiagSpill. It grooms the diagnostic overwrite into page tables, maps physical memory back to userspace, rewrites a helper process’s credentials, installs a sudoers rule, and opens a root shell; it targets x86-64 with a specific CPU/memory shape (see its README). It is destructive — it overwrites roughly 8 MiB of kernel memory and can panic the host — so run it only in a disposable VM. Do not run it on a system you are not authorised to test. Absence of your exact target from its requirements is not safety: the mechanism is fully described and the fix is public, so patch rather than rely on obscurity.

Mitigation

The real fix is a patched kernel (the bd0e9289e264 backport). Until one is installed, the only durable way to remove exposure is to keep the SCTP datapath from loading — none of the sysctl knobs that help the sibling bugs help here.

Disable the sctp and sctp_diag modules (if you don’t use SCTP)

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

sudo modprobe -r sctp_diag sctp

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

printf 'install sctp /bin/false\ninstall sctp_diag /bin/false\n' | sudo tee /etc/modprobe.d/diagspill.conf

Only do this where SCTP is genuinely unused — telephony/SIGTRAN gateways, some Diameter/RADIUS and SS7 stacks, and lksctp-based tooling need it.

Unprivileged user namespaces do not help

Disabling unprivileged user namespaces is a useful mitigation for the three sibling bugs, but not for DiagSpill: reaching the overflow needs no user namespace and no capability, only the SCTP modules. A user-namespace lockdown leaves this path fully open.

Risk notes

• Any local user is the attack surface: with sctp and sctp_diag loadable, an unprivileged account builds the oversized association and issues the diagnostic dump itself — no user namespace, no capability. This is what sets DiagSpill apart from the three bugs disclosed alongside it.
• Multi-tenant and container hosts: the demonstrated impact is local privilege escalation to root, and the discoverer notes a container with the modules available can corrupt the host kernel, so a container-to-host escape is plausible though not demonstrated.
• Remote is DoS-only, and only off-default: a remote SCTP peer can drive the transport count over an association that negotiated ADD-IP, but only if the target enabled ASCONF with SCTP-AUTH or net.sctp.addip_noauth_enable=1 (both off by default) and something on the target issues the diagnostic dump. The discoverer sees no path to remote root.
• No “too old to be affected”: the reachable defect dates to v4.7, 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.
• Backports available (CVE-2026-74469): the fix has landed upstream in 5.10.265, 5.15.216, 6.1.183, 6.6.151, 6.12.103, 6.18.44, 7.1.8, and v7.2-rc6; distro kernels that have not adopted one of those remain vulnerable.

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