CVE-2025-38457

What it actually does

Local users can trigger a null class pointer dereference in qdisc init paths (fq, hhf, choke, etc.) by specifying a non-existent parent class during tc qdisc creation, because qdisc_leaf validation occurs after qdisc_create and unconditional qlen_notify calls assume a valid class.

Why it matters to the business

Attackers with local access can crash Linux systems running network traffic control configurations, causing denial of service and availability loss; the issue affects kernels used in servers, containers, and network appliances with high ecosystem prevalence.

How an attack unfolds

An attacker with local shell access runs tc commands to add an htb root qdisc then attempts to attach an fq (or similar) qdisc to a non-existent parent class; the flawed API performs qdisc_create before validating the parent, causing qdisc_tree_reduce_backlog to invoke qlen_notify with a null class and panic the kernel. Listed threat actors and similar privilege-escalation campaigns targeting Linux kernel networking could chain this for denial of service.

How to fix it

Upgrade the Linux kernel to a version containing commit 923a276c74e25073ae391e930792ac86a9f77f1e or later stable release that enforces qdisc_leaf validation before qdisc_create; rebuild and reboot affected systems; avoid use of advanced qdiscs until patched.

How to confirm the fix worked

Confirm the running kernel git commit or package version includes 923a276c74e25073ae391e930792ac86a9f77f1e; attempt the tc qdisc reproducer commands in a test environment and verify they now return an error before qdisc creation; monitor for absence of related null-class oops in kernel logs.

Typical attack path

1. Obtain local shell or container access on a vulnerable Linux kernel
2. Create a root htb qdisc with a handle
3. Attempt to attach an fq/hhf/choke qdisc using a non-existent parent class id
4. Kernel executes qdisc init which calls qdisc_tree_reduce_backlog with null class
5. qlen_notify dereferences null pointer resulting in kernel panic or oops

How to detect it

Search kernel logs (dmesg, /var/log/kern.log, journalctl) for oops or panic messages referencing qdisc_tree_reduce_backlog, qlen_notify, or null class pointers during tc qdisc operations; correlate with audit logs of tc or netlink calls from untrusted users; review for exploitation by advanced spyware or privilege-escalation campaigns listed in threat intelligence.

What your security team should do

• Prioritize kernel updates on all internet-facing or multi-tenant Linux hosts within the CISA-style remediation window if applicable
• Restrict unprivileged use of tc and netlink qdisc APIs via SELinux/AppArmor or capabilities
• Scan for and remove non-production qdisc configurations that reference non-existent parents
• Enable kernel panic logging and watchdog to detect exploitation attempts