CVE-2026-98012 in Linux
Summary
by MITRE • 09/25/2026
In the Linux kernel, the following vulnerability has been resolved:
net/sched: sfq: clamp quantum in change path
sfq_change() accepts any non-negative quantum (only rejects (int)ctl->quantum < 0). With a crafted size table qdisc_pkt_len 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 fq_codel_change(). Reject quantum > 1<<20 with -EINVAL, matching fq_codel_change() and the init clamp.
Conditions to recreate the bug: CONFIG_NET_SCH_SFQ=y. Requires CAP_NET_ADMIN (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 size_log 15 cell_log 0
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/25/2026
The Linux kernel networking subsystem contains a critical implementation flaw within the Stochastic Fairness Queueing (SFQ) traffic control module, specifically in the change path function responsible for adjusting queue parameters. This vulnerability arises from insufficient validation of the quantum parameter during runtime configuration updates. The SFQ algorithm relies on a deficit round-robin mechanism where each flow is served based on its allocated quantum, which represents the maximum amount of data that can be transmitted before moving to the next flow in the queue. When an administrator or process with appropriate privileges modifies these parameters using tools like tc (traffic control), the kernel must ensure that all input values remain within safe operational bounds to prevent resource exhaustion or infinite loops.
The core technical flaw lies in the sfq_change() function, which previously accepted any non-negative integer for the quantum value without enforcing an upper limit. While negative values were rejected through a simple check against zero, there was no cap on excessively large positive integers. More critically, when combined with specific settings for the size table and cell log parameters, this lack of validation allows an attacker to construct a scenario where the internal deficit-refill loop spins indefinitely. Specifically, if the quantum is set to one while the qdisc_pkt_len reaches approximately two gigabytes due to crafted size tables, the kernel enters a tight loop attempting to service packets that exceed its processing capacity within reasonable timeframes. This results in the CPU being monopolized by this single operation, leading to a soft lockup condition where other processes on the system are starved of CPU cycles.
This vulnerability constitutes a Denial of Service (DoS) attack vector against local users who possess CAP_NET_ADMIN capabilities or can leverage namespace isolation techniques such as unshare with user and network namespaces to gain sufficient privileges within their own context. The impact is severe because it allows for the complete suspension of networking functionality on the affected host, potentially disrupting critical services running on that machine. From a classification perspective, this issue aligns with CWE-400: Uncontrolled Resource Consumption, as the flaw leads to excessive CPU usage and potential system hang due to unbounded loop iterations. Furthermore, in the context of the MITRE ATT&CK framework, this behavior is consistent with techniques involving resource exhaustion or denial of service via local exploitation, particularly targeting kernel-level resources that are not properly bounded by input validation checks.
The remediation for this vulnerability involves implementing strict bounds checking on the quantum parameter during configuration changes to match existing safeguards found in similar queueing disciplines like fq_codel. The fix introduces a maximum limit for the quantum value, rejecting any attempt to set it above one megabyte (1<<20) with an invalid argument error (-EINVAL). Additionally, the implementation ensures that the minimum accepted value is at least 256 bytes, preventing scenarios where extremely small quanta combined with large packet sizes could also lead to performance degradation or logic errors. This approach mirrors best practices in network stack development by ensuring consistency across different qdisc implementations and maintaining stability under edge-case configurations.
To mitigate this risk on systems that have not yet applied the kernel patch, administrators should restrict access to CAP_NET_ADMIN capabilities as much as possible through mandatory access control policies such as SELinux or AppArmor. Limiting who can modify network queueing disciplines reduces the attack surface for local privilege escalation and denial of service attacks. Furthermore, monitoring tools should be configured to detect abnormal CPU usage patterns associated with soft lockups in kernel networking threads. Once patches are available from distribution vendors, immediate application is recommended to close this gap in input validation logic within the SFQ module.