GHSA-3XRV-9P49-WQM3
Vulnerability from github – Published: 2026-10-18 18:31 – Updated: 2026-10-18 18:31In 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.
{
"affected": [],
"aliases": [
"CVE-2026-98629"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-18T16:17:15Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: cls_u32: fix manual hash table handle IDR aliasing\n\nA u32 hash table created with an explicit handle (\u0027tc filter add ...\nhandle 801: u32 divisor N\u0027) keys its IDR entry on the raw handle, while\nthe destroy paths free it under handle2id(handle). The two key domains\ndisagree for handles in the 0x800..0xFFF htid range:\nhandle2id() folds them back into the auto-allocated id space (1..0x7FF).\n\nA manual table therefore leaves its raw-keyed IDR entry unreachable on\ndelete (a permanent leak), and its delete can drop the idr entry of an\nunrelated live auto table. A later auto allocation can then hand out a\nhandle that aliases the live manual table; u32_lookup_ht() first-match\nroutes lookups and TCA_U32_LINK for that htid to the wrong table.\n\nKey the divisor-path alloc on handle2id(handle) so allocation and\nremoval share one key domain. A manual handle that maps onto an id\nalready in use is rejected with -ENOSPC, and auto allocation skips ids\nheld by live manual tables.\n\nConditions to recreate:\n ip link add test0 type dummy\n tc qdisc add dev test0 clsact\n tc filter add dev test0 ingress protocol ip pref 1 \\\n handle 801: u32 divisor 16\n tc filter add dev test0 ingress protocol ip pref 2 u32 divisor 16\n tc -d filter show dev test0 ingress | grep \u0027fh 801:\u0027\n # unpatched: two live tables with handle 0x80100000 (the pref 2 root\n # hnode is auto-allocated id 1); patched: the auto hnode takes id 2.\n\nAlso tested with a poc with a live u32 table on the block, add/delete a manual\ntable \u0027handle 901: u32 divisor 1\u0027 twice; unpatched, the re-add fails with\n-ENOSPC because the raw key leaked on the first delete.",
"id": "GHSA-3xrv-9p49-wqm3",
"modified": "2026-10-18T18:31:57Z",
"published": "2026-10-18T18:31:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98629"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0a5f5d9e94dead312d32c366b917c64e552b72f7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0fac292d93fdb313099e98cce928b3a524c92c94"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/21fc07924e996e1e661268ca269c86b8d59d25b3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2f898f9ec7c73c5697ee462681e7ea6984ee1f3d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/54a454c5e41f5e2cb70c8163140ce095c5d5eefd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f6696481eedfd5752b4b56eed715d0b0fe48b9c5"
}
],
"schema_version": "1.4.0",
"severity": []
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.