CVE-2026-98629
Low risk· EPSS 10%Exploitation Probability (EPSS)
Low risk10th percentile - higher than 10% of all known CVEs
Summary
In the Linux kernel, a bug in net/sched: cls_u32 was fixed regarding manual hash table handle IDR aliasing. A u32 hash table created with an explicit handle in the 0x800..0xFFF range keyed its IDR entry on the raw handle, while destroy paths freed it under handle2id(handle), causing a permanent IDR leak and allowing deletion of an unrelated live auto table's entry. Consequently, a later auto allocation could hand out a handle aliasing a live manual table, misrouting lookups and TCA_U32_LINK to the wrong table.
Risk Assessment
The vulnerability can cause kernel resource leaks (IDR memory) and incorrect routing of traffic filtering rules, potentially allowing bypass of QoS policies or filters. In multi-tenant environments (containers, VMs) it could be exploited to disrupt or bypass traffic isolation.
Recommendation
Update the Linux kernel to a version containing the fix (commit keying allocation on handle2id(handle)). Until patched, avoid manually creating u32 filters with handles in the 0x800..0xFFF range or restrict tc configuration to trusted users.
Other vulnerabilities in Linux kernel net/sched cls_u32
Original NVD description (English source)
In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_u32: fix manual hash table handle IDR aliasing A u32 hash table created with an explicit handle ('tc filter add ... handle 801: u32 divisor N') keys its IDR entry on the raw handle, while the destroy paths free it under handle2id(handle). The two key domains disagree for handles in the 0x800..0xFFF htid range: handle2id() folds them back into the auto-allocated id space (1..0x7FF). A manual table therefore leaves its raw-keyed IDR entry unreachable on delete (a permanent leak), and its delete can drop the idr entry of an unrelated live auto table. A later auto allocation can then hand out a handle that aliases the live manual table; u32_lookup_ht() first-match routes lookups and TCA_U32_LINK for that htid to the wrong table. Key the divisor-path alloc on handle2id(handle) so allocation and removal share one key domain. A manual handle that maps onto an id already in use is rejected with -ENOSPC, and auto allocation skips ids held by live manual tables. Conditions to recreate: ip link add test0 type dummy tc qdisc add dev test0 clsact tc filter add dev test0 ingress protocol ip pref 1 \ handle 801: u32 divisor 16 tc filter add dev test0 ingress protocol ip pref 2 u32 divisor 16 tc -d filter show dev test0 ingress | grep 'fh 801:' # unpatched: two live tables with handle 0x80100000 (the pref 2 root # hnode is auto-allocated id 1); patched: the auto hnode takes id 2. Also tested with a poc with a live u32 table on the block, add/delete a manual table 'handle 901: u32 divisor 1' twice; unpatched, the re-add fails with -ENOSPC because the raw key leaked on the first delete.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS