TUNderflow — TUN/TAP receive-headroom underflow

This tracker is no longer updated. Every maintained upstream stable line carries the fix, as do Debian, Proxmox VE 9’s default kernel, 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

ℹ️ One of four. The announcement covers four independent bugs — DirtyAH6 in IPv6 AH (xfrm), TUNderflow in TUN/TAP, PPPoEject in PPPoE, and DiagSpill in sctp_diag — each with its own tracker linked above. A kernel build that carries one fix does not necessarily carry the others: the four landed as separate commits, and a distro cherry-pick can take one without the rest. Check each tracker for the kernel you run.

How the exploitation chain works

TUN and TAP are the virtual network devices that carry packets between the kernel and a userspace process through /dev/net/tun. A device stacked on top of others can ask the devices below it to reserve extra receive headroom through the ndo_set_rx_headroom() callback, and Open vSwitch carries that request from one port of its datapath to the others — including a TUN or TAP port. Since eaea34b23c46 (v4.6, 2016) TUN honours the request by storing it in tun->align.

tun_get_user(), the write path from userspace into the kernel, uses tun->align for two things: as the headroom to reserve in front of the packet, and — through SKB_MAX_HEAD(align), the space left in a one-page skb head after that much headroom — to decide how many bytes of the packet to keep linear (good_linear). Nothing bounded align to what a page can hold. A netkit device configured with 4,096 bytes of headroom, placed under a VXLAN device on an Open vSwitch datapath, propagates a 4,160-byte request to a raw TUN port on the same datapath: SKB_MAX_HEAD(4160) underflows, good_linear becomes negative, the value wraps when assigned to the size_t linear, and the prepad + linear / len - linear arithmetic that follows wraps with it. tun_alloc_skb() then returns an skb whose skb->data sits 64 bytes past the end of its 4,096-byte head.

Everything downstream of that allocation — the protocol-byte read, skb_copy_datagram_from_iter() copying the attacker’s frame, and the receive processing on the OVS side — now reads and writes relative to a pointer outside the allocation. The copy is an out-of-bounds write of attacker-controlled bytes, the reads leak kernel memory, and a misplaced access oopses (eth_type_trans() / __skb_pull() BUG() on a TAP path, or a plain fault).

The PoC turns the write into root the way several recent kernel LPEs have: it grooms file-backed pipe buffers next to the bad TUN packet’s head, uses the Open vSwitch out-of-bounds write to set PIPE_BUF_FLAG_CAN_MERGE on one of them, and then writes through the pipe into the page cache of /etc/pam.d/su, replacing pam_rootok.so with pam_permit.so; su - root then succeeds without a password. All of the network setup needs only CAP_NET_ADMIN in a network namespace the attacker owns — which an unprivileged user namespace provides for free wherever those are enabled.

The fix, 447c9303942c, clamps the stored headroom to what a one-page skb head and a 16-bit header offset can carry (min(SKB_MAX_HEAD(0), U16_MAX - 1), less one byte for a raw TUN’s protocol byte or a full Ethernet header plus NET_IP_ALIGN for TAP), and makes tun_get_user() pskb_may_pull() those header bytes before touching them, so a nonlinear skb from another allocation path stays safe too.

⚠️ Because the introducing commit landed in v4.6 (2016), this is not a recent-regression bug: there is no in-support kernel old enough to be unaffected. Any kernel with TUN/TAP support, from 4.6 up to the fixed point releases below, is in-window. A kernel is safe only by carrying the 447c9303942c fix — not by being old.

Vulnerable commit range

The reachable lifetime runs from v4.6 through v7.1 (and 7.2 before 7.2.4). No in-support kernel predates the flaw, so the only not-affected kernels are those that carry the fix. The three sibling bugs have their own, different windows — see their trackers.

Patch status

A row is Fixed only if its kernel carries the 447c9303942c backport; every TUN-capable kernel from 4.6 on 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.3-rc1, through the netdev tree, and has been backported to every maintained stable and long-term line.

7.1.x never received it. The 7.1 line reached end of life before the backport was queued, so every 7.1 release stays vulnerable — move to 7.2 or a long-term line.

To check a tree directly: a fixed tun_set_headroom() (in drivers/net/tun.c) computes a max_headroom from SKB_MAX_HEAD(0) and U16_MAX - 1 and stores tun->align through clamp_t(); an unfixed one assigns the requested value after only a NET_SKB_PAD floor.

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 kernel rebuilt for bookworm.

Debian may fix a suite with a -security upload that cherry-picks the fix into a build numbered below the upstream first fix, so trust the security tracker, not the version number. Every suite tracked here carries the fix: bookworm’s default linux package picked it up as a Debian LTS upload, since oldstable’s security support has passed from the regular security team to the LTS team; linux-6.12 carries it via its 6.12.111-1~deb12u1 rebuild of trixie’s fixed kernel.

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

Debian’s stock kernels meet the bug’s prerequisites: tun, openvswitch, and vxlan ship as modules, netkit is built in (CONFIG_NETKIT=y), and unprivileged user namespaces are enabled by default (kernel.unprivileged_userns_clone = 1).

Proxmox VE

Proxmox ships its own Ubuntu-derived kernels, so Debian’s status does not carry over. PVE 9’s default proxmox-kernel-7.0 carries a named cherry-pick of the fix.

• 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.

TUN/TAP and Open vSwitch are routinely in use on Proxmox hosts: every VM’s network interface is a TAP device, and openvswitch-switch is a supported bridge backend. That does not widen who can trigger the bug — the attacker still needs CAP_NET_ADMIN over a network namespace.

Two audiences have such a namespace:

• an unprivileged LXC container;
• an ordinary shell account on the host, wherever unprivileged user namespaces are enabled — the default in the Ubuntu kernels PVE builds from.

Check the host with the Detection commands rather than assuming either way.

NixOS

Every NixOS channel and branch in the table defaults to linux_6_18 (linuxPackages), which carries the fix. nixpkgs also pins the older long-term series (linux_6_12, linux_6_6, linux_6_1) 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 the mid-September bumps.

master dropped linux_5_10 and linux_5_15 outright on 2026-10-06, ahead of their upcoming upstream end of life; release-26.05 still defines both, pinned at their own fixed releases.

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

All three EL lines — EL10 (6.12-based), EL9 (5.14-based) and EL8 (4.18-based) — postdate the v4.6 introduction and carry TUN/TAP, so all are in-window. RHEL 6 predates the bug and is not affected.

Red Hat advisories:

• RHEL 10: RHSA-2026:71233.
• RHEL 9: RHSA-2026:71232.
• RHEL 8: RHSA-2026:71213 (kernel-rt RHSA-2026:71016).
• RHEL 7 ELS: RHSA-2026:71687 (kernel-rt RHSA-2026:71657). Rocky ships no EL7.

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

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

All three AL2023 streams — the default kernel package (6.1 line) and the opt-in kernel6.12 and kernel6.18 packages — are fixed. Amazon backported the fix into a build numbered below the upstream first-fix release, so each stream’s ALAS names a fixed NVR below its own current build.

The CVE cross-reference reached the AL2023 repodata only once Amazon’s mirror snapshot moved forward: the advisories are dated at disclosure, but a repodata check made before that snapshot advance found no cross-reference yet and read the fix as still pending.

Amazon Linux 2 reached end of support on 2026-06-30, before this bug was disclosed. Its kernels, 4.14 on, stay vulnerable, with no fix coming — migrate to AL2023.

Detection

Is the running kernel in the affected window and missing the fix? Every TUN-capable kernel from 4.6 on is in-window; compare the running kernel against the Patch status table’s First fixed column for its series (distro builds below that number can still carry a cherry-pick — the table’s Status is the verdict):

uname -r

Is TUN/TAP available? The bug needs /dev/net/tun. Almost every distribution ships it as the tun module, autoloaded when anything opens the device node — VPN clients, QEMU/libvirt, and container runtimes all do:

ls -l /dev/net/tun

Are the headroom-propagating modules loaded? The public exploit needs Open vSwitch, VXLAN, and netkit on top of TUN. netkit is built into the kernel wherever it is enabled (CONFIG_NETKIT cannot be a module), so only the other three can show up here; a loaded module means the path is already in use, and an unloaded one is not safety, since an unprivileged network namespace can trigger its autoload:

lsmod | grep -E '^(tun|openvswitch|vxlan) '

Can an ordinary user create user namespaces? Where they can, every local user has the CAP_NET_ADMIN the bug needs. user.max_user_namespaces is the generic knob (0 disables); Debian adds kernel.unprivileged_userns_clone, and Ubuntu 24.04 and later restrict unprivileged namespaces through AppArmor (kernel.apparmor_restrict_unprivileged_userns):

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

Public PoC

The upstream PoC is in manizada/TUNderflow: a Python 3 script that builds the netkit/VXLAN/Open vSwitch topology in a private user and network namespace, grooms 4 KiB skb heads next to pipe rings holding a buffer from /etc/pam.d/su, sends the crafted TUN packets, and then writes pam_permit.so through the merged pipe before running su - root. It is tuned for two targets — Fedora 44 with 6.19.10-300.fc44.x86_64 and Ubuntu 24.04.4 with 6.17.0-40-generic — and the author notes that other kernels need their own grooming parameters, that a misplaced overwrite can hang or crash the host, and that the exploit modifies /etc/pam.d/su without rollback. Do not run it on a system you are not authorised to test, and only in a disposable VM.

Mitigation

The real fix is a patched kernel (the 447c9303942c backport). Until one is installed, the exposure is narrowed by taking away the capability or the device path the bug needs — none of these is a fix, and the researcher explicitly warns that blocking only the PoC’s modules leaves other paths to the same bug.

Disable unprivileged user namespaces

This removes the ordinary-user path to TUNderflow (and to DirtyAH6 and PPPoEject) on a multi-user host. It does nothing against a container or process that already holds CAP_NET_ADMIN, and it breaks software that relies on user namespaces — rootless container runtimes, Flatpak, browser sandboxes — so test before rolling it out. The generic knob (persist it in /etc/sysctl.d/):

sudo sysctl -w user.max_user_namespaces=0

On Debian the dedicated switch is preferable, since it leaves namespaces available to root:

sudo sysctl -w kernel.unprivileged_userns_clone=0

Block the tun module (if you don’t use TUN/TAP)

Where nothing on the host uses TUN/TAP — no VPN client, no VM or container networking through tap devices — block the module so the vulnerable code cannot be loaded; install tun /bin/false is surer than a plain blacklist tun, which only suppresses alias-based autoloading:

echo 'install tun /bin/false' | sudo tee /etc/modprobe.d/tunderflow.conf

Blocking openvswitch the same way cuts the propagation path the public exploit uses, but the CNA lists bridge/veth/GRETAP loops as alternative paths, so treat that as a speed bump rather than a mitigation.

Risk notes

• A working exploit has been public since disclosure day. Unlike many kernel CVEs, this one arrived with a tested local-root PoC for two mainstream distributions and a detailed write-up; adapting it to another kernel is grooming work, not research. Treat every in-window multi-user or container host as exploitable now.
• No kernel is too old to be affected. The bug dates from v4.6 (2016). Every in-support distribution kernel, including the RHEL 8 4.18 line and the Amazon Linux 6.1 line, is in-window and unsafe until it carries the backport.
• Backports available (CVE-2026-81000): the fix has landed in 7.3-rc1, 7.2.4, 6.18.50, 6.12.109, 6.6.157, 6.1.188, 5.15.221, and 5.10.270, and every tracked distribution ships it. Any other kernel that has not adopted one of those releases, or cherry-picked 447c9303942c, is vulnerable. The 7.1.y line is end-of-life without it.

Verification log

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

References