CVE-2026-98629 in Linux
Summary
by MITRE • 10/18/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/18/2026
The Linux kernel networking subsystem contains a critical logic error within the cls_u32 classifier module that results in identifier resource management failures and potential security vulnerabilities related to state confusion and denial of service. This vulnerability stems from an inconsistency between how hash table handles are allocated versus how they are looked up and destroyed, specifically affecting manual handle assignments in the range 0x800 through 0xFFF. The core technical flaw lies in the mismatched key domains used for identifier allocation and removal within the kernel's IDR (Identifier Resource) subsystem. When a user creates a u32 hash table with an explicit handle using commands such as tc filter add, the system keys the internal IDR entry on the raw hexadecimal value of that handle. However, during the destruction phase or when managing auto-allocated tables, the system utilizes a function called handle2id which folds handles in the problematic range back into a smaller, auto-allocated identifier space ranging from 1 to 0x7FF. This discrepancy means that for manual handles within this specific hex range, the allocation path and the deallocation path operate on different numerical keys, breaking the fundamental assumption of unique identification required for safe resource management.
The operational impact of this flaw is severe, manifesting as both a permanent memory leak and a critical state confusion vulnerability that can lead to unauthorized access or service disruption. Because the manual table's IDR entry remains keyed by its raw handle while the system attempts to free it using the folded identifier, the original entry becomes unreachable within the kernel data structures. This results in a persistent resource leak where allocated memory is never released back to the system pool. More dangerously, this mismatch allows for aliasing attacks. When an auto-allocated table subsequently requests an identifier from the IDR subsystem, it may receive an ID that corresponds to the folded version of a still-active manual handle. Consequently, subsequent lookups or link operations targeting that hash table index will incorrectly route traffic to the wrong classifier instance. This state confusion can be exploited by local attackers to bypass filtering rules, redirect network packets intended for one security policy to another, or cause kernel panics through invalid memory access patterns triggered by mismatched object references.
From a vulnerability classification perspective, this issue aligns with CWE-401 Missing Release of Memory after Effective Lifetime and CWE-829 Inclusion of Functionality from Untrusted Control Sphere due to the improper handling of resource identifiers leading to state confusion. The attack vector is primarily local, requiring an attacker with network configuration privileges to manipulate traffic control rules, which maps to MITRE ATT&CK techniques involving privilege escalation or defense evasion through system configuration manipulation. To mitigate this vulnerability, kernel developers have implemented a fix that aligns the allocation and removal key domains by ensuring that divisor-path allocations also utilize handle2id for their primary keys. This ensures consistency across all table types, whether manually assigned or auto-allocated. The patch introduces strict validation where manual handles mapping to already-in-use identifiers are rejected with an ENOSPC error code, preventing aliasing at the point of creation rather than allowing it to manifest later during lookup operations.
System administrators and developers should ensure that their Linux kernels are updated to include this specific fix for net/sched/cls_u32.c. Verification can be performed by attempting to create manual filter rules with handles in the 0x800-0xFFF range and observing whether subsequent auto-allocation correctly avoids conflicting identifiers. In unpatched systems, repeated addition and deletion of such filters will eventually fail due to leaked resources or exhibit incorrect routing behavior where traffic is directed to unintended classifier instances. The remediation strategy effectively closes this logic gap by enforcing a unified key domain for all u32 hash table operations, thereby eliminating the possibility of identifier aliasing and ensuring that resource cleanup accurately targets the correct kernel objects. This update restores the integrity of network filtering policies and prevents potential denial-of-service conditions caused by memory exhaustion from unreleased IDR entries.