CVE-2026-53080: Linux Kernel Privilege Escalation Flaw

CVE-2026-53080 Overview

CVE-2026-53080 is a NULL pointer dereference vulnerability in the Linux kernel's net/sched: cls_fw traffic classifier. The flaw stems from a race between filter publication and filter validation. Since commit ed76f5edccc9 ("net: sched: protect filter_chain list with filter_chain_lock mutex"), TC filters are added to a shared block and published to the datapath before their ->change() function is called. An invalid cls_fw "old-style" filter can classify packets before destruction, triggering a WARN_ON() in fw_classify() and a subsequent NULL dereference on q->handle.

Critical Impact
Local users with CAP_NET_ADMIN in a namespace can trigger a kernel NULL pointer dereference in fw_classify(), causing a denial of service via kernel oops on the packet transmit path.

Affected Products

Linux kernel (mainline) — net/sched/cls_fw.c classifier
Stable kernel branches receiving the backported fix
Distributions shipping affected kernel versions with TC cls_fw enabled

Discovery Timeline

2026-06-24 - CVE CVE-2026-53080 published to NVD
2026-06-24 - Last updated in NVD database

Technical Details for CVE-2026-53080

Vulnerability Analysis

The Linux kernel traffic control (TC) subsystem allows users to attach packet classifiers to qdiscs. The cls_fw classifier matches packets based on the skb->mark value. After the filter chain locking refactor, new filters are inserted into the shared filter chain and made visible to the datapath before the classifier's ->change() callback validates them.

When cls_fw receives an "old-style" creation request that later fails validation, the kernel still exposes the partially initialized filter to concurrent packet processing. During that window, fw_classify() can execute against the incomplete filter and dereference an internal queue pointer (q->handle) where q is NULL.

The issue is reproducible by attaching a clsact qdisc with an egress_block, installing a matchall filter that sets skb->mark to 65536, then adding a second fw filter on the same block while traffic flows. The marked packets enter fw_classify() before the new filter is fully validated.

Root Cause

The root cause is a publication-before-validation ordering bug. cls_fw filters added through the legacy code path become reachable from the datapath prior to ->change() completing initialization. When validation subsequently rejects the filter, the datapath has already executed fw_classify() against a filter whose internal head (q) is NULL, producing both a WARN_ON() at include/net/pkt_cls.h:88 and a NULL pointer dereference at offset 0x38.

Attack Vector

Exploitation requires local access with the ability to configure network qdiscs and filters, which generally requires CAP_NET_ADMIN within a network namespace. The reproducer chains a dummy interface, a clsact qdisc with a shared egress_block, a matchall filter that sets a high mark, and an fw filter on the same block while a userspace traffic generator transmits UDP packets. The interleaving causes packets to traverse the partially initialized filter and triggers the kernel oops on the transmit path through tcf_classify() and __dev_queue_xmit().

No verified public exploit code is available beyond the reproducer included in the upstream commit message. See the kernel commit 41845bc5 for the authoritative fix.

Detection Methods for CVE-2026-53080

Indicators of Compromise

Kernel log entries containing WARNING: and fw_classify+ stack frames from cls_fw
BUG: kernel NULL pointer dereference, address: 0000000000000038 followed by fw_classify in the call trace
Repeated tc filter add ... fw operations on shared egress_block or ingress_block chains correlated with traffic spikes

Detection Strategies

Monitor dmesg and /var/log/kern.log for fw_classify warnings and oops messages indicating exploitation attempts or accidental triggers.
Audit tc filter operations using auditd rules on netlink traffic control messages to detect rapid creation of cls_fw filters on shared blocks.
Correlate kernel oops events with the originating process identifier and namespace to identify the responsible workload or container.

Monitoring Recommendations

Enable kernel panic-on-oops in security-sensitive hosts so that exploitation attempts surface immediately rather than degrading silently.
Forward kernel logs to a centralized logging or SIEM platform and alert on cls_fw stack traces.
Track usage of CAP_NET_ADMIN inside containers and unprivileged user namespaces, since both are prerequisites for triggering the bug.

How to Mitigate CVE-2026-53080

Immediate Actions Required

Apply the upstream stable kernel fix that skips "old-style" classification on shared blocks in cls_fw.
Identify hosts running kernels that include commit ed76f5edccc9 but lack the fixing commits and prioritize them for patching.
Restrict CAP_NET_ADMIN in untrusted containers and user namespaces until patches are deployed.

Patch Information

The fix is distributed across the following stable kernel commits: 41845bc5, 4fabcfea, 5dcce34c, 5df49f05, 65782b2d, 829808cb, a719275d, and c205da70. Update to a distribution kernel that incorporates these backports.

Workarounds

Unload or blacklist the cls_fw kernel module on systems that do not require firewall-mark-based classification.
Avoid using shared egress_block or ingress_block constructs together with fw filters until patches are applied.
Drop CAP_NET_ADMIN from container security profiles and seccomp policies where TC configuration is not required.

bash

# Blacklist cls_fw if unused
echo 'blacklist cls_fw' | sudo tee /etc/modprobe.d/disable-cls_fw.conf
sudo rmmod cls_fw 2>/dev/null || true

# Verify current kernel version contains the fix
uname -r