PT-2026-98684 · Linux · Linux
CVE-2026-98021
·
Published
2026-09-25
·
Updated
2026-09-25
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
In 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.
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux