CVE-2026-68138 — Linux net/sched qdisc rate-table UAF

This tracker is no longer updated. Every maintained upstream stable line carries the fix, as do Debian, Proxmox VE 9, every tracked NixOS ref, and all three Amazon Linux 2023 kernel streams. The rows left vulnerable are Rocky Linux and the rest of the RHEL family, which Red Hat lists as affected with no fix yet, and Proxmox VE 8, which reached end of life in August 2026 without the fix.

Summary

⚠️ A local root exploit is public and the RHEL family will not be patched. The fix ships in every maintained upstream stable line (mainline, 7.2, 7.1, 6.18, 6.12, 6.6, 6.1, 5.15, and 5.10). Debian’s sid, forky, trixie, and bookworm carry it, the nixpkgs master and release-26.05 development branches have rebased onto the fixed 6.18 build, all five tracked NixOS channels (nixos-unstable, nixos-unstable-small, nixpkgs-unstable, nixos-26.05, nixos-26.05-small) have republished it, all three Amazon Linux 2023 kernel streams have shipped it (ALAS2023-2026-2106, ALAS2023-2026-2107, ALAS2023-2026-2110), and Proxmox VE 9 has shipped it in proxmox-kernel-7.0. Debian’s bullseye (EOL), every Ubuntu, Proxmox VE 8, and Rocky/RHEL had no fix when this tracker was archived (2026-09-22). Red Hat lists RHEL 8, 9 and 10 as affected, with no fix yet. Treat any multi-tenant or container host where unprivileged users or containers can reach CAP_NET_ADMIN as directly exposed, and prioritise the mitigations below until a patched kernel is available.

How the exploitation chain works

qdisc_get_rtab() and qdisc_put_rtab() manage a single process-global singly linked list, qdisc_rtab_list, and a plain non-atomic int refcnt on each struct qdisc_rate_table. That was only ever safe because every caller held the RTNL mutex, which serialised all rate-table lookups, inserts, and frees.

That invariant broke when the classifier-update path was unlocked. Since cls_flower sets TCF_PROTO_OPS_DOIT_UNLOCKED, tc_new_tfilter() keeps rtnl_held == false for it and sets TCA_ACT_FLAGS_NO_RTNL. That flag propagates through tcf_exts_validate_ex() → tcf_action_init() → tcf_action_init_1() → tcf_police_init(), which calls qdisc_get_rtab() / qdisc_put_rtab() with the RTNL mutex not held. Two RTM_NEWTFILTER requests on different CPUs, each adding a flower filter with a police action carrying the same rate table, then race on qdisc_rtab_list and on the non-atomic refcount:

BUG: KASAN: slab-use-after-free in qdisc_put_rtab+0x12f/0x160
 qdisc_put_rtab+0x12f/0x160
 tcf_police_init+0xda9/0x1590
 tcf_action_init_1+0x460/0x6b0
 tcf_action_init+0x439/0xa40
 tcf_exts_validate_ex+0x42d/0x550
 fl_change+0xddd/0x7da0
 tc_new_tfilter+0xaa7/0x2420
 rtnetlink_rcv_msg+0x95e/0xe90

The corrupted object is a ~1056-byte struct qdisc_rate_table from the kmalloc-2k slab, and because qdisc_rtab_list is a single global (not per-netns), the damage is shared system-wide. From that use-after-free / double-free the public exploit builds a five-stage chain to root:

1. Win the race. Worker threads in separate network namespaces install flower filters with police actions carrying identical rates, racing qdisc_get_rtab()/qdisc_put_rtab() until the rate table is freed with a dangling reference still live.
2. Reclaim the freed object. A classic-BPF filter program whose instruction buffer lands in kmalloc-2k reoccupies the freed rate-table slot with attacker-controlled bytes.
3. Leak. The alias is turned into a pipe_buffer disclosure, leaking live kernel pointers (a page and an ops pointer).
4. Overwrite. A forged, mergeable pipe buffer appends attacker bytes to the page-cache page backing /sbin/modprobe.
5. Root. Opening a socket with an unsupported protocol triggers a module-load, running the overwritten modprobe as root.

The fix, f43ee0c0730d, protects qdisc_rtab_list and the refcount with a dedicated qdisc_rtab_lock spinlock. The sleeping GFP_KERNEL allocation in qdisc_get_rtab() is done before the lock is taken; if a concurrent inserter added an identical table meanwhile, the freshly allocated one is freed under the lock, so no duplicate leaks.

ℹ️ The race began at v5.1, not with the rate-table code itself. qdisc_get_rtab()/qdisc_put_rtab() are far older, but they were safe as long as every caller held the RTNL mutex. The unlocked classifier path (470502de5bdb, v5.1) is what let cls_flower reach them concurrently — so a kernel whose net/sched predates that path is genuinely not affected, while every maintained line from 5.1 onward is in-window until it carries the fix.

Vulnerable commit range

The reachable window runs from v5.1 through v7.1.5 (and 7.2 before -rc5). A kernel is safe only by carrying the fix, or by predating the v5.1 unlocked-classifier path.

Patch status

A row is Fixed only if its kernel carries the f43ee0c0730d / fb29e1b41052 fix — a release at or past its branch’s first-fixed version, or an explicit distro backport. Every maintained upstream stable line now carries the fix (see the Linux kernel rows), including the new 7.2.x stable branch, which was cut after the fix had already landed and so has carried it since its first release. Debian’s sid, forky, trixie, and bookworm have rebased onto it, the nixpkgs master and release-26.05 development branches have rebased onto the fixed 6.18 build, all five tracked NixOS channels have republished it, all three Amazon Linux 2023 kernel streams have shipped it via ALAS2023-2026-2106, ALAS2023-2026-2107, and ALAS2023-2026-2110, and Proxmox VE 9’s proxmox-kernel-7.0 has shipped its cherry-pick; only Proxmox VE 8 and the Rocky Linux / RHEL family remain 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 are — for a row that is not fixed.

Linux kernel

The fix reached mainline in v7.2-rc5 and has been backported to every maintained stable and long-term line; 7.2.x has carried it from its first release.

7.1.x is end of life. Every release from 7.1.6 on carries the fix, but the line gets no further updates — move to 7.2.x or a long-term line.

Debian

bookworm’s opt-in 6.12 kernel is the separate linux-6.12 source package. Its newest build, 6.12.107-1~deb12u1, is past the 6.12 line’s first fix but was still held in Debian’s NEW queue when this tracker was archived (2026-09-22), so no host could install it and the opt-in remained vulnerable.

bullseye (Debian 11) left LTS support on 2026-08-31 and is out of Debian’s security support entirely. Its last kernel stays unpatched — upgrade to bookworm or trixie.

The vulnerable path relies on the cls_flower and act_police modules, which Debian ships and autoloads on demand; no default configuration blocks them.

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 without the fix. Its default proxmox-kernel-6.8 carries no net/sched cherry-pick, and Ubuntu marks every 6.8 kernel needed — upgrade to PVE 9.
• Older opt-in and preview series that PVE 9 and PVE 8 still publish, such as proxmox-kernel-6.17 and proxmox-kernel-6.14, ride unpatched Ubuntu bases. A host booting one should move to PVE 9’s 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_7_2, 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 that picked up the 2026-08-23 bumps.

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 the vulnerable net/sched path, so EL10, EL9 and EL8 are all affected. RHEL 6 and 7 are not affected: their 2.6.32 / 3.10 kernels predate the v5.1 path.

Red Hat’s record lists RHEL 8, 9 and 10 as affected with no fix available and no RHSA; only RHEL 8’s kernel-rt is marked “Will not fix”. Red Hat scopes the impact to a system-wide denial of service, with no mention of privilege escalation.

Until an RHSA ships, the practical response on EL hosts is the mitigations below — in particular restricting unprivileged user namespaces, which several EL deployments already do.

Rocky Linux, AlmaLinux, CloudLinux and Oracle Linux’s Red Hat Compatible Kernel rebuild RHEL’s kernel, so their status follows Red Hat’s: 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. Each stream’s fixed build sits below its line’s upstream first fix, because Amazon backports fixes into its own builds — judge an AL2023 kernel by its ALAS, not its version number.

Amazon Linux 2 reached end of support on 2026-06-30 — migrate to AL2023.

Detection

Is the running kernel in the affected window and missing the fix? Every kernel from v5.1 up to the fixed releases is in-window. Compare the running kernel against the Patch status table’s First fixed column for its series — every maintained upstream line now has one, so a distro kernel below its line’s first-fixed version (and without its own backport) is still vulnerable:

uname -r

Can an unprivileged user reach CAP_NET_ADMIN? The unprivileged local path in the public exploit needs unprivileged user namespaces. If both of these are non-zero, an ordinary user can unshare -Urn into a namespace where it holds CAP_NET_ADMIN:

sysctl kernel.unprivileged_userns_clone user.max_user_namespaces

Are the classifier and action modules available? The race needs cls_flower and act_police, which autoload on a matching tc command. modinfo takes several module names and prints the on-disk path of each (an error for any that is absent):

modinfo -F filename cls_flower act_police

Is this a multi-tenant or container host? Any context where an unprivileged user, or a container holding CAP_NET_ADMIN (for example one run with --cap-add=NET_ADMIN or a privileged pod), can issue tc commands is directly exposed, regardless of the user-namespace sysctls:

grep -rEl 'CAP_NET_ADMIN|NET_ADMIN|privileged' /etc/containers /etc/kubernetes 2>/dev/null

Public PoC

There is a public working exploit. aramosf/CVE-2026-68138 ships exploit.c, a self-contained program that escalates an unprivileged user (uid=1000) to root in the initial namespace by driving the qdisc race and the five-stage chain described above. The author reports it reproduced against Ubuntu 22.04 GA (5.15.0-187) in a VM, and that the vulnerable code is present in Ubuntu 22.04 HWE, 24.04, and 26.04 kernels (with the specific chain tuned for the 5.15 target).

The exploit needs a fairly specific environment — x86-64, at least four vCPUs, unprivileged user and network namespaces enabled, the NET_CLS_FLOWER / NET_CLS_ACT / NET_ACT_POLICE config options, roughly 5 GiB of RAM, and a per-process file-descriptor limit of at least 4096 — but those are ordinary defaults on many desktop and server kernels. A working exploit being public means this should be treated as exploited-in-practice, not theoretical: patch or apply the mitigations below.

Mitigation

The real fix is a patched kernel (a release at or past 7.2-rc5 / 7.1.6, or a distro backport of f43ee0c0730d). Until one is installed, the exposure can be narrowed — none of these is a fix.

Restrict unprivileged user namespaces

The unprivileged local path depends on user namespaces to obtain CAP_NET_ADMIN. Where unprivileged user namespaces are not needed, disabling them closes that path (it does not stop a process or container that already holds CAP_NET_ADMIN). On Debian/Ubuntu kernels:

sudo sysctl -w kernel.unprivileged_userns_clone=0

Persist it across reboots:

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

On kernels without that Debian/Ubuntu knob, cap the count instead:

sudo sysctl -w user.max_user_namespaces=0

Block the classifier and action modules

Where tc flower filtering with a police action is not used, blocking the modules removes the datapath — including for a privileged or container caller, which the user-namespace knob does not. install … /bin/false is surer than a plain blacklist, which only suppresses alias autoloading:

printf 'install cls_flower /bin/false\ninstall act_police /bin/false\n' | sudo tee /etc/modprobe.d/cve-2026-68138.conf

That rule only prevents future autoload — it does not remove a module already resident. Where the modules are loaded but idle, unload them so the block takes effect now:

sudo modprobe -r act_police cls_flower

A module that is genuinely in use cannot be unloaded, and on a host actively running tc flower+police you could not block it without breaking that service — so there the rule has no effect until the workload stops (or a reboot with the rule already in place). It is likewise inert if either module is built into the kernel (=y) rather than loadable; the modinfo check above prints a .ko path only for a loadable module.

Only do this where flower-based traffic control is genuinely unused; some container networking, QoS, and SDN stacks rely on it and must fall back to the other measures.

Restrict who holds CAP_NET_ADMIN

On multi-tenant and container hosts, review which workloads are granted CAP_NET_ADMIN: drop it from container capability sets that do not need it, avoid privileged containers, and keep untrusted workloads out of namespaces where they can run tc. This shrinks the reachable surface but leaves a trusted-but-hostile caller in scope.

Risk notes

• Multi-tenant and container hosts are the exposure. The demonstrated impact is local privilege escalation to root, so any host where an unprivileged user or a container can reach CAP_NET_ADMIN and run tc is directly in scope — a public exploit exists.
• The RHEL family is the gap. The fix reaches every maintained upstream stable line. Debian’s sid, forky, trixie, and bookworm have rebased onto it, as have the nixpkgs master and release-26.05 branches and all five tracked NixOS channels that republish them, all three Amazon Linux 2023 kernel streams have shipped it, and Proxmox VE 9 has shipped its cherry-pick, but Proxmox VE 8 and the Rocky Linux / RHEL family had no fix when this tracker was archived (2026-09-22). Check the First fixed column, not the kernel’s age.
• No Red Hat fix yet. RHEL 8, 9 and 10 are listed as affected with no fix available, so EL hosts should rely on the mitigations rather than waiting for an RHSA.
• No “module not present” escape. Unlike some kernel CVEs, the vulnerable code is core net/sched (built in with CONFIG_NET_SCHED); only cls_flower / act_police are modules, and they autoload on demand. Reachability turns on CAP_NET_ADMIN and user namespaces, not on whether a module is already loaded.

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