DirtyAH6 — IPv6 AH routing-header out-of-bounds write

This tracker is no longer updated. Every tracked kernel carries the fix except Debian bookworm’s opt-in linux-6.12 — a host booting that kernel should switch back to bookworm’s default kernel, which is fixed.

Summary

How the exploitation chain works

The IPv6 Authentication Header (AH) protects a packet’s immutable fields with an ICV. Because a type-0 routing header is mutable in transit, AH6 must first rewrite it into the form it will have at its final destination before the ICV is computed or verified. That rewrite is ipv6_rearrange_rthdr() in net/ipv6/ah6.c.

The function derives the number of addresses in the routing header from its hdrlen field, then walks a pointer using segments - segments_left. For packets that arrive through the normal input path, hdrlen and segments_left were already validated, so the code assumed segments_left <= segments. That assumption does not hold for a raw IPv6 HDRINCL packet, where the sender supplies the header bytes directly. A routing header with hdrlen = 2 describes a single address but can carry segments_left = 255.

With those values the pointer moves 4,064 bytes backwards, and a 4,064-byte length is handed to memmove() — an out-of-bounds access that reads and writes memory adjacent to the packet’s skb head, including the skb_shared_info that follows the linear data area. The PoC grooms that corruption into a controlled overwrite: it sources data from /etc/pam.d/su, uses the corrupted metadata to decrypt chosen bytes into the PAM configuration page, and swaps pam_rootok.so for pam_permit.so so that su yields a root shell.

The fix, 7bad4bda74dc, validates the invariant locally — if (segments_left > segments) return -EINVAL; — before any pointer arithmetic, and propagates the error through the existing AH6 input and output paths.

ℹ️ Only a patched kernel flips a verdict; the other conditions are reachability, not the fix. The local-root path needs the AH6/XFRM code reachable and a way to inject a raw crafted packet: either unprivileged user + network namespaces, or CAP_NET_ADMIN plus CAP_NET_RAW over an attacker-controlled netns. A host that disables unprivileged user namespaces removes the ordinary-user route but not an appropriately-capable container or process. Separately, a host that acts as an IPv6 router/gateway and applies AH in transport mode can be driven into the same bug by a remote packet — a crash/DoS, and only with difficult on-target grooming anything more. These gates decide exposure; they never substitute for the backport, and they live in the prose below, not in the table.

Vulnerable commit range

The reachable lifetime is therefore 2.6.12 through 7.2 without the backport.

Patch status

A row is Fixed only if its kernel carries the 7bad4bda74dc backport; every AH6-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 each row’s newest build when the tracker was last updated.

Because the flaw predates the git era, there are no “not affected” kernel rows — no maintained line is old enough to escape it, so a kernel is safe only by carrying the fix. Every maintained upstream stable line picked up the backport in its 2026-09-02 point release; the mainline row carries it from v7.3-rc1.

Linux kernel

The fix reached mainline in v7.3-rc1 and has been backported to every maintained stable line.

7.1.x is end of life. Its last release, 7.1.13, is also the first to carry the fix, but the line gets no further updates — move to 7.2.x or a long-term line.

The mishandled segments_left dates to the start of the git era, so no branch predates the bug. AH6 itself is the INET6_AH module (ah6.ko), built by every mainline configuration that enables IPv6 AH; the vulnerable rearrangement runs whenever a packet takes the AH6 input or output path.

Debian

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

Every default kernel in the table is fixed; the bookworm opt-in is not. sid, forky, trixie and bookworm’s default kernels all carry the fix, but linux-6.12 is a separate source package that had not been rebuilt from trixie’s fixed source when this tracker stopped — a host that opted into it should switch back to bookworm’s default kernel.

bullseye (Debian 11) left LTS support on 2026-08-31, before the fix reached any 5.10 point release. No fix is coming — upgrade to bookworm or newer.

Proxmox VE

Proxmox ships its own Ubuntu-derived kernels, so Debian’s status does not carry over; Proxmox VE is x86-only. PVE 9’s default proxmox-kernel-7.0 has carried the fix since a direct cherry-pick, now folded into its Ubuntu base.

• PVE 8 reached end of life in August 2026, before any fix reached its kernels. Its default proxmox-kernel-6.8 and the bookworm-backports opt-in proxmox-kernel-6.14 stay vulnerable, and no fix is coming — upgrade to PVE 9.
• Abandoned preview series that PVE 9 still publishes, proxmox-kernel-6.17 and proxmox-kernel-6.14, will never get 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_1, linux_5_15 and linux_5_10 at fixed releases, so a host overriding the default to an older long-term series 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 IPv6 AH, so all three EL lines — EL10 (6.12-based), EL9 (5.14-based) and EL8 (4.18-based) — are in-window. Rocky 8 and 10 skipped the exact RHSA build and shipped the next one.

• RHEL 7 ELS: fixed by RHSA-2026:71687 (kernel-rt RHSA-2026:71657). Rocky ships no EL7.
• RHEL 8 kernel-rt (NFV): fixed by RHSA-2026:71016.
• RHEL 9 and 10 kernel-rt: fixed by the same advisories as the regular kernel.

The usual route for an ordinary user to reach this bug is an unprivileged user namespace. RHEL 8 disables those by default (user.max_user_namespaces = 0); RHEL 9 and 10 enable them. The RHEL 8 default does not protect a suitably privileged container or a process granted CAP_NET_ADMIN + CAP_NET_RAW, so treat it as an exposure reducer, not a fix.

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. All three streams shipped the fix in the build already current at disclosure — Amazon routinely backports into a build numbered below the upstream first fix, so the ALAS, not the version number, is what confirms a stream is fixed.

Detection

Is the running kernel in the affected window and missing the fix? Every AH6-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 ah6 module available or loaded? The bug lives in the IPv6 AH transform. ah6 autoloads when an AH6 SA or an AH-bearing packet needs it:

lsmod | grep -E '^(ah6|xfrm)'

Can this host reach the local-root path? The ordinary-user route needs unprivileged user namespaces; without them an attacker needs CAP_NET_ADMIN + CAP_NET_RAW over a network namespace instead. Check the namespace policy:

sysctl kernel.unprivileged_userns_clone user.max_user_namespaces 2>/dev/null

Is AH6 autoload blocked? Where AH6 is genuinely unused, a blacklist/install … /bin/false entry stops the transform from autoloading — though a capable caller can still request it:

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

Public PoC

The upstream PoC is in manizada/DirtyAH6; it demonstrates the unprivileged-local-user to root chain on specific targets (Fedora 43 and Ubuntu 24.04 kernels) and is destructive — it overwrites /etc/pam.d/su with no rollback. Do not run it on a system you are not authorised to test; use a disposable VM.

Mitigation

The real fix is a patched kernel (the 7bad4bda74dc backport). Until one is installed, the exposure is narrowed by keeping the AH6 transform unreachable and closing the ordinary-user injection path — none of these is a fix.

Disable unprivileged user namespaces

This removes the standard ordinary-user route to the bug (it does not stop an appropriately-capable container or process). For the current boot:

sudo sysctl -w kernel.unprivileged_userns_clone=0

Persist it across reboots:

echo 'kernel.unprivileged_userns_clone = 0' | sudo tee /etc/sysctl.d/99-dirtyah6.conf

On kernels without that Debian/Ubuntu knob, cap the namespace count with user.max_user_namespaces = 0 instead.

Block the ah6 module (if AH6 is unused)

Most hosts never terminate IPv6 AH. Where it is genuinely unused, block the transform so the vulnerable code cannot autoload; install ah6 /bin/false is surer than a plain blacklist ah6:

echo 'install ah6 /bin/false' | sudo tee /etc/modprobe.d/dirtyah6.conf

Only do this where IPsec AH for IPv6 is genuinely unused.

On an IPv6 router/gateway

A host that applies AH in transport mode while forwarding IPv6 is remotely reachable for a crash/DoS. Until it is patched, restrict which peers can send AH-protected traffic to it, and prefer ESP or a patched kernel before exposing AH-transport processing to untrusted networks.

Risk notes

• Multi-tenant and container hosts are the primary exposure: an unprivileged local user (via user namespaces) or a container/process with CAP_NET_ADMIN + CAP_NET_RAW can reach the bug and, per the PoC, escalate to root — even with no remote peer. Disabling unprivileged user namespaces closes the ordinary-user route but not the capable-caller one.
• IPv6 AH-transport gateways add a remote surface: a host adding AH in transport mode as an IPv6 router can be driven into the same out-of-bounds by a remote packet — a crash/DoS, and only with difficult on-target grooming anything worse.
• No “too old to be affected”: the flaw predates the git era, so old LTS kernels are not safe by age. Every maintained upstream line carries the fix, but distro kernels adopt it independently — check the First fixed column for the distro in question, not the kernel’s age.
• Backports available (CVE-2026-80844): the fix has landed in mainline 7.3-rc1 and stable 7.2.3, 7.1.13, 6.18.49, 6.12.108, 6.6.156, 6.1.187, 5.15.220, and 5.10.269; 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