CVE-2026-98010: net/sched: drr: clamp quantum in change class
In the Linux kernel, the following vulnerability has been resolved:
net/sched: drr: clamp quantum in change class
drrchangeclass() rejects explicit quantum==0 but falls back to pschedmtu() with no floor. With a crafted size table qdiscpktlen reaches ~2 GiB, so quantum=1 (or a zero pschedmtu on a headerless device) makes the deficit-refill loop spin under the qdisc lock.
Add clampt(u32, quantum, 256, 1<<20) after the zero reject and on the fallback path. The explicit-zero reject is preserved.
Conditions to recreate the bug: CONFIGNETSCHDRR=y. Requires CAPNETADMIN (namespace-local via unshare -Urn suffices).
tc qdisc add dev dummy0 root drr tc class add dev dummy0 parent 1: classid 1:1 drr quantum 1
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
After rejecting an explicit quantum of zero, clamp quantum with clamp_t(u32, quantum, 256, 1<<20) in drr_change_class(); apply this for CONFIG_NET_SCH_DRR=y.
Linux kernel DRR qdisc (drr_change_class) quantum validation = clamp_t(u32, quantum, 256, 1<<20)
Event History
Frequently Asked Questions
Who can realistically trigger this issue?
An attacker needs CAP_NET_ADMIN. This can be obtained within a local user and network namespace using unshare -Urn, so systems that permit unprivileged user namespaces may expose the issue to local unprivileged users.
What configurations are affected?
The DRR traffic scheduler must be enabled with CONFIG_NET_SCH_DRR=y. Triggering requires configuring a DRR qdisc and class with a very small quantum, or reaching the fallback path on a headerless device where psched_mtu() is zero.
What is the impact of successful exploitation?
A crafted size table can cause packet length processing near 2 GiB. With quantum set to 1, or a zero fallback MTU, the deficit-refill loop can spin while holding the qdisc lock, causing a denial of service.
What can be done before a fix is deployed?
Restrict CAP_NET_ADMIN and, where feasible, disable or limit unprivileged creation of user and network namespaces. Avoid DRR configurations with very small quantum values and avoid the affected fallback condition on headerless devices.