---
id: "CVE-2026-98629"
kind: "vulnerability"
aliases: ["CVE-2026-98629"]
title: "Linux kernel: u32 classifier table handles can alias and leak memory"
severity: "unknown"
cvss: null
epss: null
exploited: false
status: "open"
category: "infrastructure"
products: []
ecosystems: []
tags: ["infrastructure", "kernel", "linux", "networking", "tc"]
not_affected_if: ["no-tc-u32-filters"]
published_at: "2026-10-18T16:17:15+00:00"
first_seen_at: "2026-10-23T21:57:16+00:00"
updated_at: "2026-10-25T05:21:07+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98629", "first_seen_at": "2026-10-23T21:57:16+00:00"}]
---

# Linux kernel: u32 classifier table handles can alias and leak memory

The Linux kernel's traffic-control u32 classifier mishandles IDR keys for manually created hash tables, so deleting one can leak its entry or drop an unrelated live table's entry. A later auto-allocated handle can then alias a live manual table and misroute lookups, and an unprivileged local attacker is not stated in the sources.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- Run `uname -r` and compare against the fixed kernel in your distribution's advisory (unknown from these sources).
- Check whether tc u32 is in use: `tc -d filter show dev <iface> ingress` and look for `u32 divisor` entries with explicit handles like `fh 801:`.

## Fix

- Update the Linux kernel to a release that includes the upstream commit fixing cls_u32 manual hash table handle IDR aliasing (fixed version unknown from these sources).
- Reboot into the patched kernel after updating.

## Timeline

- 2026-10-23T21:57:16+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-98629

## From the sources

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.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_