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

Summary

⚠️ A local root exploit is public and most distributions are unpatched. The fix shipped upstream in v7.2-rc5 and the 7.1.6 stable release, but at the time of writing no maintained 6.x or 5.x stable line carries the backport, and no Debian, Ubuntu, Proxmox, NixOS, Rocky/RHEL, or Amazon Linux kernel has shipped a fix. Red Hat has marked RHEL 9 and 10 “Will not fix.” 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 7.2-rc5 / 7.1.6, or an explicit distro backport. Every maintained 6.x or 5.x line is in-window and, at the time of writing, still Vulnerable: the fix has not been backported below 7.1.6. 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 stay — until a row is fixed.

Linux kernel

The fix reached Linus in v7.2-rc5 (tagged 2026-07-26) and was backported to the 7.1.6 stable release (fb29e1b41052, tagged 2026-08-03). No other stable line carries it. The 6.18, 6.12, 6.6, 6.1, 5.15, and 5.10 long-term lines are all in-window — the race was introduced at v5.1 and each of these is past that — and none has picked up the backport, so a host on any current point release of those lines is vulnerable and stays so until its branch takes the fix, most likely in a later stable batch. These unpatched long-term lines are the bulk of the exposure, because nearly every distribution ships from one of them.

Debian

Debian’s status splits on which upstream branch each suite tracks. sid follows the 7.1 line and has been fixed since the 7.1.6-1 upload (7.1.6 is the branch’s first-fixed release), first seen in the archive 2026-08-04. testing (forky, the future Debian 14) likewise tracks the 7.1 line: it jumped straight from the vulnerable 6.12.94-1 to 7.1.8-1 when that kernel migrated on 2026-08-17 — the suite’s first kernel past the 7.1.6 first fix — so it is fixed too.

Every Debian stable suite is still vulnerable, because each rides an unpatched line: trixie (Debian 13) rides the 6.12 line, bookworm (Debian 12) the 6.1 line, and bullseye (Debian 11 LTS) the 5.10 line. None of those stable lines has the backport, and the Debian security tracker marks all three suites open with no DSA issued. They will follow once the 6.12.y / 6.1.y / 5.10.y stable lines gain the fix or Debian cherry-picks it. The bookworm linux-6.12 and bullseye linux-6.1 opt-in kernels rebuild the same still-unpatched source lines, so they are vulnerable too.

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. Both maintained series are vulnerable: PVE 9’s default proxmox-kernel-7.0 and PVE 8’s default proxmox-kernel-6.8. Neither carries a net/sched cherry-pick in its packaging, and Ubuntu’s security tracker marks every 7.0 and 6.8 kernel needed (no fixed build yet), so the silent-rebase path has not delivered the fix either. A Proxmox kernel turns fixed only once its Ubuntu base ships the patch or Proxmox cherry-picks it.

PVE 9 and PVE 8 also still publish older opt-in / preview kernel series (proxmox-kernel-6.17, -6.14 and the like) that ride equally unpatched Ubuntu bases; a host booting one of those is vulnerable until it moves to a fixed kernel.

NixOS

Every tracked ref’s default linuxPackages is linux_6_18 — a 6.18.y release with no backport, so every tracked ref is vulnerable. Kernel updates land on nixpkgs master and release-26.05 first, and each channel republishes them once its Hydra jobset passes; the -small channels (nixos-unstable-small, nixos-26.05-small) are gated on a reduced jobset and typically lead their siblings. The nixpkgs-unstable channel — what a bare nixpkgs flake registry input resolves to — is a separate channel aimed at non-NixOS Nix users and can hold a different kernel from nixos-unstable.

nixpkgs does package a fixed linux_7_1 (past the 7.1.6 first fix), but it is not the default; a host stays vulnerable unless it explicitly overrides boot.kernelPackages to a fixed series. Overriding to an older series (linux_6_1 / linux_5_15 / linux_5_10) is likewise vulnerable.

Rocky Linux / RHEL family

RHEL-family kernels are long-lived forks. Red Hat’s CVE record (CSAF/VEX, initial release 2026-08-10, CVSS 7.0) marks RHEL 8, 9, and 10 affected — their kernels carry the unlocked-classifier path — and ships no fix: RHEL 9 and RHEL 10 are flagged “Will not fix”, and RHEL 8 has no fix available, with no RHSA. So every in-support EL stream is vulnerable and, per Red Hat’s stated intent, is expected to stay that way. Red Hat offers no written rationale, but scopes the impact to a system-wide denial of service and rates the flaw Moderate, with no mention of privilege escalation — a lower assessment than the demonstrated local-root exploit, and the basis for declining to backport a fix. Rocky rebuilds RHEL unchanged, so its status tracks Red Hat’s; AlmaLinux (typically the fastest rebuild) has published no erratum either. Oracle Linux and CloudLinux track the RHEL determination.

RHEL 6 and RHEL 7 are not affected — their 2.6.32 / 3.10 kernels predate the v5.1 unlocked-classifier path, so Red Hat records them known_not_affected. Both are end-of-life and out of scope here. The niche kernel-rt real-time kernel shares the base kernel’s exposure.

Because Red Hat does not plan a fix, the practical response on EL hosts is the mitigations below — in particular restricting unprivileged user namespaces, which several EL deployments already do.

Amazon Linux

No ALAS has been issued for this CVE, so every AL2023 kernel stream is vulnerable: the default kernel (the 6.1 line) and the kernel6.12 and kernel6.18 opt-ins. All three are in-window without the backport; each turns fixed only when Amazon ships a cherry-pick or the stream crosses a fixed upstream release. Amazon Linux 2 reached end of support on 2026-06-30 and is not tracked.

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 — only 7.2-rc5+ / 7.1.6+ (or a distro backport) is fixed:

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.
• Distributions are broadly unpatched. The fix reached only mainline and the 7.1 stable line; every maintained 6.x / 5.x line, and every tracked distribution kernel, is still vulnerable at the time of writing. Check the First fixed column, not the kernel’s age.
• Red Hat does not plan a fix. RHEL 9 and 10 are marked “Will not fix” and RHEL 8 has 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