CVE-2026-98013: net/sched: fq_pie: clamp quantum in change path
In the Linux kernel, the following vulnerability has been resolved:
net/sched: fqpie: clamp quantum in change path
fqpiechange() accepts any quantum value from userspace, including 1. With a crafted size table qdiscpktlen reaches ~2 GiB, so quantum=1 makes the deficit-refill loop spin ~2^31 times under the qdisc lock (a soft lockup / denial of service).
Add max(256U, ...) matching fqcodelchange().
Conditions to recreate the bug: CONFIGNETSCHFQPIE=y. Requires CAPNETADMIN (namespace-local via unshare -Urn suffices).
tc qdisc add dev dummy0 root fqpie tc qdisc change dev dummy0 root fqpie quantum 1 stab data 32768 sizelog 15 celllog 0
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Clamp the fq_pie quantum in the change path with max(256U, ...), so userspace cannot set quantum below 256U.
Linux kernel fq_pie qdisc quantum = minimum 256U
Event History
Frequently Asked Questions
Who can trigger this issue?
An attacker needs CAP_NET_ADMIN. This capability can be obtained within a local user and network namespace using unshare -Urn, so the issue is relevant where unprivileged users are permitted to create such namespaces.
What configurations are affected?
The kernel must be built with CONFIG_NET_SCH_FQ_PIE=y, and an fq_pie qdisc must be configured. Exploitation uses an fq_pie change operation with quantum set to 1 and a crafted size table.
What is the operational impact of exploitation?
The deficit-refill loop can run roughly 2^31 times while holding the qdisc lock. This can cause a soft lockup and denial of service.
How can administrators mitigate the issue before applying the fix?
Restrict CAP_NET_ADMIN and, where appropriate, prevent unprivileged users from creating user and network namespaces. Avoid allowing fq_pie qdisc changes with very small quantum values, particularly quantum 1.