CVE-2026-98629

Published: Ott 18, 2026 Last Modified: Ott 19, 2026

ExploitDB:

Other exploit source:

Google Dorks:

Description

AI Translation Available

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.

AI Generated Translation

Nel kernel Linux, è stata risolta la seguente vulnerabilità:

net/sched: cls_u32: correzione dell'aliasing dell'IDR handle manuale della hash table

Una hash table u32 creata con un handle esplicito ('tc filter add ... handle 801: u32 divisor N') utilizza il suo IDR come chiave basata sul handle grezzo, mentre i percorsi di distruzione la liberano tramite handle2id(handle). I due domini di chiavi sono discordanti per gli handle nell'intervallo 0x800..0xFFF: handle2id() li riduce nel spazio di ID auto-allocati (1..0x7FF).

Di conseguenza, una tabella manuale lascia il suo entry IDR con chiave grezza irraggiungibile dopo la cancellazione (perdita permanente), e la sua eliminazione può eliminare l'entry IDR di una tabella auto-attiva non correlata. Una successiva allocazione automatica può quindi assegnare un handle che è alias di una tabella manuale attiva; u32_lookup_ht() per le route con primo match e TCA_U32_LINK per quell'htid puntano alla tabella sbagliata.

Si modifica l'allocazione del percorso divisor in modo che sia basata su handle2id(handle), affinché allocazione e rimozione condividano lo stesso dominio di chiavi. Un handle manuale che mappa su un ID già in uso viene rifiutato con -ENOSPC, e l'allocazione automatica salta gli ID attualmente in uso da tabelle manuali attive.

Condizioni per ricreare la vulnerabilità:
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:'
# non patchato: due tabelle attive con handle 0x80100000 (l'hnode root pref 2 è ID auto-allocato 1); patchato: l'hnode auto assume ID 2.

È stato anche testato con un proof of concept che utilizza una tabella u32 attiva sul blocco, aggiungendo e rimuovendo due volte una tabella manuale 'handle 901: u32 divisor 1'; non patchato, il riaggiunta fallisce con -ENOSPC perché la chiave grezza viene leakata durante la prima cancellazione.