CVE-2026-74583 in Linux
Summary
by MITRE • 08/21/2026
In the Linux kernel, the following vulnerability has been resolved:
net/sched: cls_route: fix fastmap use-after-free on filter
The route4 classifier maintains a 16-slot fastmap cache that stores raw struct route4_filter pointers indexed by (id, iif). The reader (route4_classify) populates this cache via route4_set_fastmap() for every classified packet that hits a filter. The writer (route4_delete, route4_change) clears the cache via route4_reset_fastmap() before RCU-deferred kfree of the filter.
This creates a UAF race: 1. Reader walks the RCU-protected bucket chain, finds filter f 2. Writer unlinks f, calls route4_reset_fastmap(), then tcf_queue_work() 3. Reader calls route4_set_fastmap() and writes f into the cache *after* the writer's reset, caching a pointer about to be freed 4. After the RCU grace period, kfree(f) executes 5. Next classified packet on the same (id, iif) tuple hits the stale fastmap entry and reads f->res from freed memory
Reproduced with an mdelay(100) accelerator in route4_set_fastmap() and a concurrent add/delete stress test (provided by both zdi and Santosh). Both triggered KASAN slab-use-after-free reports in the route4 fastmap paths.
Fix: Introduce a per-filter boolean dying flag to suppress stale fastmap republishing by in-flight readers.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/21/2026
The vulnerability identified as CVE-2023-something (specifically affecting net/sched/cls_route.c) represents a critical use-after-free condition within the Linux kernel’s traffic control subsystem, specifically involving the route4 classifier and its fastmap caching mechanism. This flaw arises from an improper synchronization strategy when managing concurrent access to filter structures that are subject to Read-Copy-Update (RCU) semantics. The route4 classifier utilizes a 16-slot fastmap cache designed to optimize packet classification by storing raw pointers to struct route4_filter objects, indexed by the combination of class ID and input interface identifier. This optimization is critical for high-throughput network environments where repeated lookups on the same traffic flows are common. However, the implementation fails to adequately protect these cached pointers against race conditions during filter deletion or modification operations, leading to memory corruption when stale references are dereferenced after the underlying objects have been freed.
The technical root cause lies in a timing window between reader and writer threads operating on the RCU-protected data structures. The reader thread, executing within route4_classify for every incoming packet that matches a filter, invokes route4_set_fastmap to populate or update the fastmap cache with pointers to active filters. Simultaneously, the writer thread, triggered by administrative actions such as deleting or changing a filter via route4_delete or route4_change, is responsible for removing the filter from the RCU-protected bucket chain and subsequently freeing its memory. The vulnerability manifests because the writer clears the fastmap cache using route4_reset_fastmap before initiating the deferred free operation through tcf_queue_work. However, there exists a race condition where an in-flight reader may have already retrieved the pointer to the filter but has not yet written it into the fastmap cache. If this write occurs after the reset but before the RCU grace period expires and kfree is executed, the system caches a dangling pointer. Once the grace period elapses and the memory is reclaimed, any subsequent packet matching the same tuple will access the freed memory via the stale fastmap entry, resulting in undefined behavior or kernel panic.
This vulnerability aligns with CWE-416: Use After Free, as it involves accessing memory that has been deallocated by another part of the system due to a lack of proper synchronization. From an offensive security perspective, this flaw maps closely to ATT&CK technique T1059.008: Scripting via Linux/Unix Commands or more specifically kernel exploitation techniques involving race conditions and memory corruption such as those described in MITRE CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization (Race Condition). The ability to trigger a slab-use-after-free condition allows an attacker, potentially requiring only local unprivileged access depending on the configuration of traffic control rules, to corrupt kernel heap structures. This can lead to privilege escalation, denial of service through system crashes, or arbitrary code execution if the freed memory is reallocated for sensitive data that can be controlled by the attacker. The vulnerability was successfully reproduced using stress tests involving concurrent add and delete operations with artificial delays inserted into the fastmap setting function, confirming the existence of the race window via KASAN reports.
The resolution involves introducing a per-filter boolean flag named dying to synchronize access between readers and writers more effectively. This flag is set by the writer thread before initiating the RCU cleanup process, signaling that the filter is in the process of being destroyed. The reader thread checks this flag within route4_set_fastmap; if the dying flag is active, the reader suppresses the publication of the stale pointer into the fastmap cache. This ensures that no new references to the soon-to-be-freed object are cached while existing readers complete their operations and exit the RCU read-side critical sections. By preventing the caching of invalid pointers during this transitional state, the kernel avoids dereferencing freed memory in subsequent packet classifications. Mitigation strategies for administrators who cannot immediately patch include restricting access to traffic control configuration tools such as tc, ensuring that only trusted users can modify qdiscs and filters, and monitoring system logs for signs of instability or crashes related to network subsystems. Regularly updating the kernel to a version containing this fix is the primary remediation path to eliminate this race condition vulnerability.