CVE-2026-74583: net/sched: cls_route: fix fastmap use-after-free on filter
In the Linux kernel, the following vulnerability has been resolved:
net/sched: clsroute: fix fastmap use-after-free on filter
The route4 classifier maintains a 16-slot fastmap cache that stores raw struct route4filter pointers indexed by (id, iif). The reader (route4classify) populates this cache via route4setfastmap() for every classified packet that hits a filter. The writer (route4delete, route4change) clears the cache via route4resetfastmap() 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 route4resetfastmap(), then tcfqueuework() 3. Reader calls route4setfastmap() 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 route4setfastmap() 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.
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this race?
Systems using the Linux route4 traffic-control classifier are exposed when packet classification can run concurrently with route4 filter deletion or modification. The stale cache entry is associated with the same (id, iif) tuple used by later classified packets.
What conditions are needed to trigger the use-after-free?
A reader must find a route4 filter while a writer concurrently unlinks that filter and resets the fastmap cache. The reader can then repopulate the cache with the removed filter pointer before its RCU-delayed free, and a subsequent packet matching the same tuple can dereference it.
How can I tell whether this is occurring?
The issue was reproduced with concurrent route4 filter add/delete activity and produced KASAN slab-use-after-free reports in the route4 fastmap paths. Those reports, particularly during concurrent classifier updates and packet processing, indicate the race may be occurring.