CVE-2026-74583: Linux Kernel Route4 Use-After-Free Flaw

CVE-2026-74583 Overview

CVE-2026-74583 is a use-after-free vulnerability in the Linux kernel's net/sched subsystem, specifically the cls_route classifier. The route4 classifier maintains a 16-slot fastmap cache that stores raw struct route4_filter pointers indexed by (id, iif). A race between the reader path (route4_classify) and the writer path (route4_delete, route4_change) allows an in-flight reader to republish a stale filter pointer into the fastmap after the writer has already scheduled the filter for RCU-deferred kfree. Subsequent classified packets then dereference freed memory.

Critical Impact
A local attacker with CAP_NET_ADMIN privileges can trigger memory corruption in the kernel, leading to code execution, privilege escalation, or system crash.

Affected Products

Linux kernel versions containing the cls_route classifier fastmap implementation
Distributions shipping upstream stable kernels prior to the fix commits
Systems where the cls_route traffic classifier is loadable or in use

Discovery Timeline

2026-08-21 - CVE-2026-74583 published to the National Vulnerability Database (NVD)
2026-08-25 - Last updated in NVD database

Technical Details for CVE-2026-74583

Vulnerability Analysis

The route4 classifier in net/sched/cls_route.c uses a 16-slot fastmap cache to accelerate lookups of previously matched filters. Reader threads populate this cache through route4_set_fastmap() after successfully classifying a packet. Writer threads clear entries through route4_reset_fastmap() before queuing the filter for RCU-deferred deallocation via tcf_queue_work().

The race window emerges because the reader captures the filter pointer during its RCU-protected bucket-chain walk, then writes that pointer to the fastmap without rechecking whether the filter has been unlinked. If a writer executes route4_reset_fastmap() between the reader's pointer acquisition and its cache store, the reader republishes a pointer that will be freed after the current RCU grace period.

Root Cause

The root cause is missing synchronization between fastmap publication and filter teardown. The reader has no mechanism to observe that a filter has entered its dying state, so route4_set_fastmap() will cache pointers that the writer has already marked for destruction. Both external researchers reproduced the issue by inserting an mdelay(100) accelerator in route4_set_fastmap() and running a concurrent add/delete stress test, which produced KASAN slab-use-after-free reports.

Attack Vector

Exploitation requires local access with the ability to configure traffic control classifiers, typically CAP_NET_ADMIN inside the initial network namespace or root within an unprivileged user namespace where net admin capabilities are exposed. An attacker races filter creation and deletion against packet traffic that exercises the route4 classifier, driving the reader and writer into the vulnerable window. Successful exploitation reads or corrupts freed slab memory through the stale f->res dereference, which can be steered toward kernel information disclosure or control-flow hijacking depending on slab reuse.

The upstream fix introduces a per-filter boolean dying flag. Writers set this flag before calling route4_reset_fastmap(), and readers check it in route4_set_fastmap() to suppress republication of pointers already destined for kfree. See the Linux Kernel Commit b969984 for the reference fix.

Detection Methods for CVE-2026-74583

Indicators of Compromise

KASAN reports flagging slab-use-after-free in route4_classify or route4_set_fastmap call paths
Unexpected kernel oops, panic, or general protection fault traces referencing cls_route symbols
Unusual tc filter add and delete churn on the route classifier from non-administrative workloads

Detection Strategies

Monitor kernel ring buffer (dmesg, journalctl -k) for KASAN, BUG, or oops entries citing route4 functions
Audit tc qdisc and tc filter operations through auditd rules on the tc binary and netlink RTM_NEWTFILTER / RTM_DELTFILTER messages
Track processes invoking network namespace creation followed by rapid classifier manipulation, a common local privilege escalation pattern

Monitoring Recommendations

Enable kernel lockdown, KASAN, or SLUB debug in test fleets to surface exploitation attempts during validation
Forward kernel logs and audit events to a centralized SIEM and alert on repeated cls_route fault signatures
Baseline legitimate CAP_NET_ADMIN usage and alert on anomalous invocations by unprivileged service accounts or containerized workloads

How to Mitigate CVE-2026-74583

Immediate Actions Required

Apply the upstream stable kernel updates that introduce the per-filter dying flag in cls_route and reboot affected hosts
Restrict CAP_NET_ADMIN and user namespace creation on multi-tenant and container hosts until patches are deployed
Inventory running kernels with uname -r and cross-reference against distribution advisories for backported fixes

Patch Information

The fix is available across multiple upstream stable branches. Reference commits include Linux Kernel Commit 0e7a8cf, Linux Kernel Commit 47d7f70, Linux Kernel Commit 5ec9001, Linux Kernel Commit 7897198, Linux Kernel Commit 820f083, Linux Kernel Commit a17f636, Linux Kernel Commit ae9aff8, and Linux Kernel Commit b969984. Consume the fix through your distribution's stable kernel update channel.

Workarounds

Blacklist the cls_route4 module where no workloads depend on the route classifier and unload it with modprobe -r cls_route
Disable unprivileged user namespaces where policy permits by setting kernel.unprivileged_userns_clone=0 to reduce the local attack surface
Enforce mandatory access control profiles (SELinux, AppArmor) that deny classifier manipulation from untrusted service accounts

bash

# Configuration example: prevent cls_route4 from loading and reduce local attack surface
echo 'install cls_route4 /bin/true' | sudo tee /etc/modprobe.d/disable-cls_route4.conf
sudo sysctl -w kernel.unprivileged_userns_clone=0
echo 'kernel.unprivileged_userns_clone=0' | sudo tee -a /etc/sysctl.d/99-hardening.conf