ZDI-26-575: TOCTOU in Linux Kernel Net Scheduler Enables Local…

A TOCTOU race condition in the Linux kernel's Net Scheduler packet classifier API allows local privilege escalation. The fix introduces new locking primitives in the traffic control subsystem.

On August 13, 2026, the Trend Micro Zero Day Initiative published advisory ZDI-26-575, documenting a local privilege escalation vulnerability in the Linux kernel. The flaw resides in the Net Scheduler Packet Classifier API, a component of the traffic control (tc) subsystem, and stems from a Time-Of-Check Time-Of-Use (TOCTOU) race condition caused by insufficient locking during operations on shared objects. The disclosure concludes a coordinated disclosure window of roughly seven weeks; the vendor was notified on June 25, 2026.

Key Takeaways

Advisory ZDI-26-575 documents a Linux kernel LPE vulnerability published August 13, 2026, with vendor notification on June 25, 2026.
The mechanism is a TOCTOU race condition in the Net Scheduler traffic classifier: an inconsistent read of the pedit key count between check and use during hardware offload.
The attacker must already possess the ability to execute code with elevated privileges on the target system to exploit the flaw.
Commit 8b519cb in the official torvalds/linux repository fixes the vulnerability by introducing the function tcf_pedit_nkeys_locked() with serialization via spin_lock_bh.

The Mechanism: A Classic TOCTOU in the tc Subsystem

The core of the vulnerability is a Time-Of-Check Time-Of-Use race condition in the Linux Net Scheduler traffic classifier, specifically in the act_pedit module that handles packet editing operations in the traffic control framework. ZDI describes the flaw precisely: "The specific flaw exists within the traffic classifier. The issue results from the lack of proper locking when performing operations on an object." Concurrent access to the tcfp_nkeys field — the number of packet modification keys — occurs without adequate protection, allowing the value read during verification to differ from the one actually used in the subsequent operation.

This inconsistency manifests in the context of traffic control hardware offload, where the kernel delegates tc rule processing to NIC components. While calculating the number of actions to offload, the code iterates over extensions and pedit actions without guaranteeing the stability of the key counter. The result is a heap out-of-bounds write: writing beyond the bounds of the area allocated for packet editing structures.

The ZDI advisory is clear on the consequences: "An attacker can leverage this vulnerability to escalate privileges and execute code in the context of the kernel." Kernel-mode code execution completes the escalation: from already-privileged local access to total system control.

The Technical Fix: Manual Locking, Not Automatic Abstraction

The correction in Linus Torvalds' official repository, commit 8b519cb with the message "net/sched: act_pedit: fix TOCTOU heap OOB write in tc offload," adopts an explicit, manual approach to synchronization. The change introduces the function tcf_pedit_nkeys_locked(), accompanied by the annotation lockdep_assert_held(&a->tcfa_lock) which enforces static verification of the lock. The commit comment is unequivocal: "Must be called with act->tcfa_lock held to ensure consistency of parallel reads of the same action's pedit keys."

Existing calls to tcf_pedit_nkeys() in the offload functions tcf_offload_act_num_actions_single() and tcf_exts_num_actions() are replaced with the locked version, wrapped in spin_lock_bh(&act->tcfa_lock) and spin_unlock_bh(&act->tcfa_lock) pairs. The choice of spin_lock_bh — which disables bottom halves but not softirqs indiscriminately — indicates the developers balanced the need for mutual exclusion against the requirement not to excessively block the network path.

This pattern is revealing. After three decades of Linux kernel development, the networking subsystem still requires manual locking interventions rather than benefiting from automatic abstractions that prevent entire classes of race conditions. The corrected TOCTOU is not the product of an architectural redesign, but of a targeted audit that identified a specific vulnerability window and closed it with existing primitives.

Why the Risk Perimeter Extends Beyond a Single Server

The advisory specifies that the attacker must already have the ability to execute high-privileged code on the target system. This initial condition does not diminish the severity: in multi-tenant environments, containerized platforms, and cloud infrastructure, escalation from container to host or from privileged user to kernel mode is a critical leap in the threat model.

Systems that centralize network traffic management via tc — edge servers, Kubernetes nodes with elaborate network policies, virtualization hosts with SR-IOV or hardware offloading — expose the net/sched subsystem to a significant attack surface. Traffic control is a component enabled by default in many enterprise and cloud configurations, not an optional module rarely loaded.

The dossier does not document specific affected kernel versions, nor the presence of in-the-wild exploits. These gaps make it impossible to quantify real-world exposure, but they do not attenuate the intrinsic criticality of a kernel-mode LPE in such a widely deployed networking subsystem.

Immediate Actions

The following actions derive directly from the facts documented in the sources:

Verify the presence of commit 8b519cb in your kernel baseline: the fix is in the torvalds/linux repository and must be integrated into distribution releases.
Monitor release notes from enterprise distribution vendors (Red Hat, SUSE, Canonical, Debian) for application of the specific patch to the act_pedit module.
Assess patching priority based on actual usage of tc with hardware offload: systems that do not enable this configuration have reduced exposure, though the net/sched subsystem remains present.
Await assignment of a CVE identifier for traceability in your vulnerability management system, as the ZDI advisory does not specify a CVE at the time of publication.

"An attacker can leverage this vulnerability to escalate privileges and execute code in the context of the kernel." — ZDI Advisory ZDI-26-575

FAQ

Why does the Linux kernel continue to exhibit TOCTOU race conditions after decades of development?

The networking subsystem operates in high-frequency, low-latency paths where locking overhead has historically been minimized. The choice of spin_lock_bh in the current fix, rather than a redesign of the concurrency model, confirms that performance optimizations continue to prevail over automatic correctness guarantees.

Does the absence of CVE and CVSS in the ZDI advisory limit vulnerability management?

The lack of a CVE identifier and a numerical CVSS score in the extracted text of advisory ZDI-26-575 complicates integration into automated prioritization systems, but does not reduce the documented technical severity: LPE with kernel-mode execution is inherently critical.

Information verified against cited sources and current as of publication.

Sources

Sources and references