DiagSpill — SCTP sock_diag transport-count overflow

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 tracks the live package or point release; First fixed and Fixed since are set once, when a row first carries the fix, and stay — until then.

Linux kernel

The fix reached Linus in v7.2-rc6 (tagged 2026-08-02) and the kernel CNA backported it across the maintained stable lines in two waves. The first, on 2026-08-09, covered 6.6.151 (546221b86cee), 6.12.103 (09e722030e81), 6.18.44 (4ba5bf7ed50f), and 7.1.8 (6201cd1d70f1) — each the same fix by subject, confirmed present on its linux-*.y branch. The three older long-term lines followed on 2026-08-19: 6.1.183 (80f48523a0fe), 5.15.216 (dfea32dd76f3), and 5.10.265 (b453e00da121). Every maintained upstream line now carries the fix.

v7.2 was released on 2026-08-16; since the fix landed by v7.2-rc6, the GA release and the new 7.2.x stable branch carry it from the start. 7.1.x reached end of life at 7.1.13 per kernel.org’s finger_banner, already fixed since 7.1.8, so that row’s verdict is settled and its Current kernel stops moving.

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

Debian’s status splits on which upstream branch each suite tracks. sid carries the 7.1 line and has been fixed since the 7.1.8-1 upload (upstream 7.1.8 is the 7.1 branch’s first-fixed release); forky (testing, the future Debian 14) since that same 7.1.8-1 migrated to testing. trixie (Debian 13) shipped 6.12.105-1 through DSA-6466-1, past the 6.12 branch’s 6.12.103 first fix. bookworm (Debian 12, now on LTS) is fixed via DLA-4777-1, a bookworm-security upload of 6.1.187-1 — well past the 6.1 branch’s 6.1.183 first fix.

bookworm also offers an opt-in newer kernel, the linux-6.12 source package (the trixie 6.12 kernel rebuilt for bookworm and shipped through bookworm-security). Its earlier 6.12.101-1~deb12u1 build predated the fix; its 6.12.107-1~deb12u1 build (past 6.12.103) carries it. The security tracker does not assess this CVE against the opt-in package by name, so its verdict is a version compare against the branch’s first-fixed release.

bullseye (Debian 11) reached the end of its LTS support window on 2026-08-31 and gets no rows here: the security tracker no longer carries a bullseye entry for this CVE, and its 5.10-line kernel predates the 5.10.265 first fix. It is permanently vulnerable — no further update is coming through the standard LTS, so a host still on bullseye should upgrade to bookworm or newer.

SCTP is not built into Debian’s kernel image; it ships as the sctp module, autoloaded on first use of an SCTP socket and not blacklisted by default, 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 kernels, so Debian’s status does not carry over. PVE 8’s proxmox-kernel-6.8 backports the fix as a named cherry-pick (…-sctp-prevent-peer-transport-count-overflow.patch), first in 6.8.12-43 (2026-08-18). The 6.8 base is old, but the Ubuntu-derived kernel carries SCTP and received the cherry-pick, so a pre-fix Proxmox series is not safe by base version alone.

PVE 9’s proxmox-kernel-7.0 is staged, not yet shipped. The published pve-no-subscription build rebases Ubuntu-7.0.0-38.38, whose stable content reaches only 7.1.7 — one release short of the 7.1 branch’s 7.1.8 first fix — and carries no named DiagSpill cherry-pick. The pve-kernel git tree has since moved past that point: an unreleased changelog entry syncs the Ubuntu submodule through upstream stable 7.1.8–7.1.13, spanning the fix, but Ubuntu’s own resolute advisory for this CVE is still pending and the newer build has not reached pve-no-subscription. The row stays vulnerable in practice until the fix ships in a published build.

PVE 8 additionally offers proxmox-kernel-6.14 as a bookworm-backports opt-in for newer hardware support. It is vulnerable: its Ubuntu base predates Ubuntu’s own fix, it carries no cherry-pick, and Ubuntu’s linux-hwe-6.14 on noble is end-of-life, so no further Ubuntu-side rebase will bring the fix — only a direct Proxmox cherry-pick would close it, and none has landed.

Both releases also still publish pre-GA preview kernel series that Proxmox abandoned before this disclosure and that never received the fix — PVE 9’s proxmox-kernel-6.14 and proxmox-kernel-6.17, and PVE 8’s proxmox-kernel-6.2 and proxmox-kernel-6.5. No fix is coming for any of them; a host still booting one of these preview kernels stays vulnerable until it switches to its release’s current default kernel.

NixOS

Every tracked ref’s default linuxPackages is linux_6_18, at or above the 6.18 branch’s 6.18.44 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, so a channel can sit a few days behind master, and an unstable channel is not necessarily ahead of a release channel. The -small channels are gated on a reduced jobset and pick up kernel updates fastest. nixpkgs also currently pins linux_6_1 / linux_5_15 / linux_5_10 / linux_6_6 / linux_6_12 at or above their first-fixed releases, so a host overriding the default to one of those on a current-enough ref is fixed as well.

The master and release-26.05 rows are the git branches the fix lands on; they are not Hydra-gated, so they carry the kernel bump from the moment the commit lands — typically a day or more before a channel republishes it, which the Fixed since dates down the group reflect. They are development branches, not deployment targets. A bare github:NixOS/nixpkgs follows master; github:NixOS/nixpkgs/nixos-unstable tracks the nixos-unstable channel; a bare nixpkgs registry input resolves to nixpkgs-unstable, a separate channel not gated on the NixOS tests.

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 published a CVE assessment (initial release 2026-08-15) rating the kernel Affected across EL8/9/10 but has not shipped a fix — no vendor_fix remediation and no RHSA — so every stream is vulnerable pending an advisory.

Module posture reduces reachability on a stock EL host: sctp.ko and sctp_diag.ko are not in the base kernel packages but in kernel-modules-extra, which installs /etc/modprobe.d/sctp-blacklist.conf (blacklist sctp, plus sctp_diag) alongside them. So sctp never autoloads on a stock EL host — without kernel-modules-extra the modules are absent, and with it the blacklist suppresses autoload. An explicit modprobe sctp still loads it where the package is installed, so this does not close the local vector. Rocky rebuilds RHEL 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

All three AL2023 kernel streams are now fixed, on staggered advisories. The kernel6.18 opt-in shipped ALAS2023-2026-2106 (2026-08-31) at 6.18.44-99.149, and the kernel6.12 opt-in ALAS2023-2026-2110 (2026-08-31) at 6.12.103-127.188 — both at their branch’s first fix. The default kernel stream (6.1 line) shipped later, in ALAS2023-2026-2143 (2026-09-14), fixing it at 6.1.186-228.374 — past the 6.1 branch’s 6.1.183 first fix. AL2 reached end of support on 2026-06-30 and gets no rows; it is out of scope for further core-package security updates.

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