CVE-2026-98012: net/sched: sfq: clamp quantum in change path
In the Linux kernel, the following vulnerability has been resolved:
net/sched: sfq: clamp quantum in change path
sfqchange() accepts any non-negative quantum (only rejects (int)ctl->quantum < 0). 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(). Reject quantum > 1<<20 with -EINVAL, matching fqcodelchange() and the init clamp.
Conditions to recreate the bug: CONFIGNETSCHSFQ=y. Requires CAPNETADMIN (namespace-local via unshare -Urn suffices).
tc qdisc add dev dummy0 root sfq tc qdisc change dev dummy0 root sfq quantum 1 stab data 32768 sizelog 15 celllog 0
Affected Software
Event History
Frequently Asked Questions
Who can trigger this issue in practice?
An attacker needs CAP_NET_ADMIN to modify an SFQ qdisc. This capability can be obtained within a local user and network namespace using unshare -Urn, so systems that permit unprivileged user namespaces may expose this to local unprivileged users in their own namespaces.
What configurations are affected?
The SFQ scheduler must be built into the kernel, with CONFIG_NET_SCH_SFQ=y. Exploitation also requires the ability to create or change an SFQ qdisc on a network device.
What is required to reproduce the denial of service?
The vulnerable change path requires a crafted size table that lets the qdisc packet length reach roughly 2 GiB, combined with a quantum of 1. This causes the deficit-refill loop to iterate about 2^31 times while holding the qdisc lock, resulting in a soft lockup or denial of service.
What can be done before a fix is deployed?
Restrict CAP_NET_ADMIN and, where appropriate, prevent unprivileged creation of user and network namespaces. Avoid allowing users to apply SFQ qdisc changes with very small quantum values and crafted size-table parameters.
How does the fix constrain quantum values?
The fix clamps the quantum to at least 256 and rejects values greater than 1<<20 with -EINVAL. This aligns the SFQ change path with the existing initialization behavior and fq_codel change-path limits.