CVE-2026-53080

What it actually does

This vulnerability is a Linux kernel denial-of-service flaw in the traffic control classifier subsystem, specifically the cls_fw firewall-mark classifier used by net/sched. Under a race/ordering condition, an invalid old-style cls_fw filter can be published to a shared traffic-control block before its change/validation routine completes. Packets may then be classified through this partially initialized or invalid filter, causing fw_classify() to hit a WARN_ON() and then dereference a NULL pointer. The result is a kernel oops or crash, and on systems configured to panic on oops, a full system reboot or outage. Exploitation generally requires the ability to create or modify traffic-control filters, typically root or CAP_NET_ADMIN privileges, although container or namespace configurations that grant network administration capabilities can increase practical exposure.

Why it matters to the business

Successful exploitation can crash affected Linux systems or interrupt networking workloads that depend on them. The primary consequence is availability loss: servers, network appliances, container hosts, or virtualized workloads may reboot, hang, or lose service depending on kernel configuration and workload placement. Because exploitation requires local network-administration privileges and there is no known public exploit maturity or KEV listing, broad internet-scale exploitation is unlikely, but environments that delegate CAP_NET_ADMIN to containers, automation jobs, or less-trusted users should treat this as higher priority.

How an attack unfolds

An attacker with sufficient local privileges first obtains the ability to manipulate Linux traffic-control configuration, such as root access or CAP_NET_ADMIN in a relevant network namespace. They create or use a network interface and attach a clsact qdisc or shared traffic-control block. They then add filters in a sequence that causes an old-style cls_fw filter to be inserted into the shared block before validation rejects or destroys it. While that invalid filter exists briefly, the attacker generates traffic with packet marks that cause the classifier path to evaluate the invalid filter. The kernel enters fw_classify(), reaches the inconsistent state, and dereferences a NULL pointer. Depending on kernel configuration, this produces a kernel warning, oops, networking disruption, or system panic/reboot.

How to fix it

Apply the vendor-provided Linux kernel update that includes the upstream fix for net/sched cls_fw handling of old-style classification on shared blocks. Where fixed package versions are not listed, use the latest stable kernel from the operating-system vendor or distribution security channel and confirm that the patch titled similar to "net/sched: cls_fw: fix NULL dereference of old filters before change()" is included. Reboot into the fixed kernel after installation. As interim mitigation, restrict CAP_NET_ADMIN to trusted users and workloads, avoid granting privileged or network-admin capabilities to containers unless required, disable unprivileged user namespaces where appropriate, and remove or blacklist the cls_fw module if firewall-mark traffic-control classification is not used. Review automation that creates tc qdisc/filter objects and remove unsupported old-style cls_fw usage.

How to confirm the fix worked

Confirm the running kernel is updated, not just installed, by checking the active kernel version after reboot and comparing it with the vendor advisory or changelog containing the cls_fw fix. Verify whether cls_fw is present or loaded with tools such as lsmod, modinfo, or distribution package metadata. Inspect traffic-control configuration with tc qdisc show and tc filter show to identify clsact qdiscs, shared blocks, and fw filters. Validate mitigation by confirming untrusted users and containers do not have CAP_NET_ADMIN and cannot run tc filter add operations. Review kernel logs after testing or normal operation to ensure there are no new fw_classify(), cls_fw, NULL pointer dereference, or include/net/pkt_cls.h warnings.

Typical attack path

1. Gain local access with root privileges, CAP_NET_ADMIN, or equivalent ability to configure Linux traffic control.
2. Create or select a network interface where traffic-control filters can be attached.
3. Attach a clsact qdisc or shared traffic-control block to the interface.
4. Add traffic-control filters including a matchall action that sets a packet mark and an old-style cls_fw filter.
5. Generate a high volume of matching packets while the invalid filter is briefly visible to the datapath.
6. Trigger fw_classify() to process the invalid filter and dereference a NULL pointer.
7. Cause a kernel oops, panic, reboot, or network-service interruption.

How to detect it

Look for evidence in kernel logs, system journals, audit logs, shell history, EDR telemetry, and container runtime logs. Key artifacts include kernel warnings or oopses referencing fw_classify, cls_fw, include/net/pkt_cls.h, tcf_classify, tc_run, __dev_queue_xmit, or a NULL pointer dereference near address 0000000000000038. Correlate those events with recent execution of tc commands that add qdiscs, shared blocks, or fw filters, especially commands using "tc qdisc add ... clsact", "tc filter add block", "matchall", "skbedit mark", or "prio ... fw". Also review process execution for packet generators or high-rate local traffic tools launched immediately before the crash. In containerized environments, check whether a container with CAP_NET_ADMIN executed tc or generated traffic shortly before the host kernel warning, oops, panic, or reboot. Because this flaw primarily causes denial of service and does not create a stable persistent artifact, detection should focus on crash telemetry and pre-crash command/activity correlation.

• fw_classify
• cls_fw
• include/net/pkt_cls.h:88
• BUG: kernel NULL pointer dereference, address: 0000000000000038
• WARNING: ./include/net/pkt_cls.h:88
• tcf_classify
• tc_run
• __dev_queue_xmit
• tc qdisc add dev
• egress_block
• clsact
• tc filter add block
• matchall action skbedit mark
• tc filter add block 1 protocol ip prio 2 fw
• skbedit mark 65536
• RIP: 0010:fw_classify
• Modules linked in: cls_fw
• old-style classification on shared blocks

What your security team should do

• Prioritize patching Linux systems that grant CAP_NET_ADMIN to containers, network automation, CI jobs, tenants, or non-administrative operators.
• Update to a vendor-supported kernel containing the cls_fw net/sched fix and reboot into the patched kernel.
• Inventory hosts using Linux traffic control, clsact qdiscs, shared tc blocks, or cls_fw filters.
• Remove CAP_NET_ADMIN from containers and service accounts unless explicitly required.
• Disable or blacklist cls_fw where it is not operationally needed, after confirming no traffic-shaping or classification dependency exists.
• Monitor kernel logs for fw_classify, cls_fw, pkt_cls.h warnings, kernel oopses, and unexpected reboots.
• Review audit, shell, and EDR telemetry for suspicious tc qdisc or tc filter commands executed shortly before crashes.
• Treat repeated kernel oopses or reboots following tc filter activity as potential exploitation or unsafe automation until proven otherwise.