GHSA-XP4J-CC89-XJ49
Vulnerability from github – Published: 2026-09-25 12:31 – Updated: 2026-09-25 12:31In the Linux kernel, the following vulnerability has been resolved:
net: reject oversized tx_queue_len at netlink parse time
rtnl_create_link() assigns IFLA_TXQLEN directly to dev->tx_queue_len without going through netif_change_tx_queue_len(), so a device created with "ip link add ... txqueuelen 500000" bypasses the S16_MAX cap and still triggers the oversized ring allocations in pfifo_fast, tun and tap. The veth peer nest (rtnl_nla_parse_ifinfomsg()) and the RTM_NEWLINK-on-existing-device path reach the same sinks.
Enforce the cap in ifla_policy instead: IFLA_TXQLEN becomes NLA_POLICY_FULL_RANGE(NLA_U32, &txqlen_range) with txqlen_range = { .min = 0, .max = S16_MAX }. All netlink consumers parse against this policy - rtnl_setlink(), rtnl_newlink() (create and change), and the veth peer nest - so every netlink path is capped at parse time and rejects the attribute with -ERANGE plus a proper "integer out of range" extack message before any device state is modified (the RTM_SETLINK half-application wart is gone with it).
Document the bound in the rt-link.yaml netlink spec.
Conditions to recreate the bug: - CONFIG_NET_SCHED=y, CONFIG_VETH=y, CONFIG_USER_NS=y, CONFIG_NET_NS=y. - Unprivileged user in a fresh user+net namespace (unshare -Urn): ip link add v0 txqueuelen 500000 type veth peer name v1 -> on the fixed kernel this is rejected with -ERANGE ("integer out of range" extack) instead of installing an oversized tx_queue_len that later inflates pfifo_fast/tun/tap ring allocations. - ip link set v0 txqueuelen 500000 is likewise rejected at parse time.
{
"affected": [],
"aliases": [
"CVE-2026-98021"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-25T11:17:30Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: reject oversized tx_queue_len at netlink parse time\n\nrtnl_create_link() assigns IFLA_TXQLEN directly to dev-\u003etx_queue_len\nwithout going through netif_change_tx_queue_len(), so a device created\nwith \"ip link add ... txqueuelen 500000\" bypasses the S16_MAX cap and\nstill triggers the oversized ring allocations in pfifo_fast, tun and\ntap. The veth peer nest (rtnl_nla_parse_ifinfomsg()) and the\nRTM_NEWLINK-on-existing-device path reach the same sinks.\n\nEnforce the cap in ifla_policy instead: IFLA_TXQLEN becomes\nNLA_POLICY_FULL_RANGE(NLA_U32, \u0026txqlen_range) with\ntxqlen_range = { .min = 0, .max = S16_MAX }. All netlink consumers\nparse against this policy - rtnl_setlink(), rtnl_newlink() (create\nand change), and the veth peer nest - so every netlink path is capped\nat parse time and rejects the attribute with -ERANGE plus a proper\n\"integer out of range\" extack message before any device state is\nmodified (the RTM_SETLINK half-application wart is gone with it).\n\nDocument the bound in the rt-link.yaml netlink spec.\n\nConditions to recreate the bug:\n- CONFIG_NET_SCHED=y, CONFIG_VETH=y, CONFIG_USER_NS=y, CONFIG_NET_NS=y.\n- Unprivileged user in a fresh user+net namespace (unshare -Urn):\n ip link add v0 txqueuelen 500000 type veth peer name v1\n -\u003e on the fixed kernel this is rejected with -ERANGE (\"integer out\n of range\" extack) instead of installing an oversized tx_queue_len\n that later inflates pfifo_fast/tun/tap ring allocations.\n- ip link set v0 txqueuelen 500000 is likewise rejected at parse time.",
"id": "GHSA-xp4j-cc89-xj49",
"modified": "2026-09-25T12:31:33Z",
"published": "2026-09-25T12:31:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98021"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1aa9e143bf51405665a793d4cc925e1c4f0c5922"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2fd0880f0272ec022906a05587fd91416ebecc38"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/45ca9f59b6c7ea70e0a17054902b8a556913db34"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a638a2625aa83160a394abe8e8b2e524a80c771b"
}
],
"schema_version": "1.4.0",
"severity": []
}
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.
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.