CVE-2026-98427 in Linux
Summary
by MITRE • 10/14/2026
In the Linux kernel, the following vulnerability has been resolved:
net/sched: codel: bound the dropping loop per dequeue call
The CoDel control law schedules the next drop one interval/sqrt(count) after the previous drop, using the configured interval (codel_params.interval). For very small intervals the scheduled step rounds down to zero, so the dropping loop in codel_dequeue() never advances and drains the entire backlog under the qdisc lock in one call - an unprivileged user can trigger a soft lockup this way.
Fix in the shared codel code used by both codel and fq_codel:
1. Make the control-law step at least 1 tick so the dropping loop always moves forward.
2. Cap the dropping loop at CODEL_MAX_DROPS_PER_DEQUEUE (256) drops per codel_dequeue() call, resyncing drop_next to now when the cap is hit: the catch-up owed to the loop grows with the idle gap and the backlog, which no interval threshold can bound. This is a deliberate behaviour change after long idle gaps.
The cap applies to fq_codel (4b549a2ef4be) and the mac80211 TXQ path (fixed interval, cap only).
The target sojourn delay (codel_params.target) is not validated: it does not feed the control law, so a sub-tick value is aggressive rather than deadlock-prone.
Conditions to recreate the bug: - tc qdisc add dev lo root handle 1: tbf rate 1kbit burst 2kb limit 1000000 - tc qdisc add dev lo parent 1:1 handle 10: codel interval 2us target 1ms noecn limit 1000000 (same for fq_codel) - unpatched kernel: tc accepts it; a UDP flood under the 1kbit tbf soft-lockups (watchdog: BUG: soft lockup) while one codel_dequeue() call drops the backlog under the qdisc lock - patched kernel: same setup, at most 256 drops per dequeue call, no soft lockup
Testing: claim reproducer and interval 2us/3us variants run clean; tdc qdisc category passes (see the selftests patch).
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/14/2026
The Linux kernel networking subsystem contains a vulnerability within the Controlled Delay CoDel queueing discipline implementation that allows for denial of service through soft lockups. This flaw resides in the codel_dequeue function, which is responsible for managing packet drops to maintain network congestion control parameters. The core issue arises from how the algorithm calculates the timing interval between consecutive packet drops. Specifically, the scheduling logic determines the next drop time based on a formula involving the configured interval divided by the square root of the current count of packets in the queue. When an administrator configures an extremely small interval value, such as two microseconds, the calculated step size can round down to zero due to integer arithmetic limitations within the kernel's tick-based timing system.
When this rounding results in a zero-step duration, the dropping loop inside codel_dequeue fails to advance its internal state variables appropriately relative to the current time. Consequently, the condition for exiting the drop loop is never met because the algorithm perceives that it has not yet reached the scheduled next drop time, which remains effectively at or before the current timestamp. This creates an infinite loop where the function continuously drops packets from the queue backlog without yielding control back to the scheduler. Because this operation occurs while holding the qdisc lock, other kernel threads attempting to access the same network device are blocked indefinitely. An unprivileged local user can exploit this condition by configuring a traffic control rule with a minimal interval and then generating high-volume UDP traffic that exceeds the configured rate limit, thereby triggering the soft lockup and rendering the system or specific network interfaces unresponsive until manually reset.
The vulnerability impacts both the standard codel implementation and its variant fq_codel, which is often used in wireless networking stacks via mac80211 TXQ paths. The operational impact includes severe performance degradation and potential complete system instability due to watchdog timeouts detecting the non-responsive kernel thread. This represents a significant availability risk as it requires no special privileges beyond standard network configuration capabilities, making it accessible to any user with appropriate tc command permissions or API access. The flaw highlights the dangers of allowing unbounded loops in critical path code that operates under spinlocks, particularly when input parameters can influence loop termination conditions through arithmetic edge cases.
To mitigate this vulnerability, the Linux kernel maintainers have implemented a two-part fix within the shared codel control law code. First, the algorithm now enforces a minimum step size of one tick, ensuring that the dropping loop always makes forward progress in time calculations regardless of how small the configured interval is set by the user. This prevents the zero-step scenario that leads to infinite looping. Second, and more critically for long-term stability, a hard cap has been introduced on the number of drops allowed per single dequeue call. This limit is defined as CODEL_MAX_DROPS_PER_DEQUEUE, currently set to two hundred fifty-six packets. If this threshold is reached during a dequeue operation, the loop terminates early, and the drop_next timestamp is resynchronized with the current time.
This cap serves as an essential safeguard against scenarios where long idle gaps or massive backlogs would otherwise cause excessive processing time even if the interval calculation were correct. By limiting drops per call, the kernel ensures that other processes retain CPU time slices, preventing soft lockups while still applying necessary congestion control measures over subsequent dequeue calls. This behavior change is deliberate and applies to both codel and fq_codel implementations as well as related mac80211 TXQ paths. Although the target sojourn delay parameter was noted in analysis for not being strictly validated against sub-tick values, this does not currently lead to deadlock conditions but rather results in more aggressive dropping behavior which is functionally acceptable within the control law's design parameters.
From a classification perspective, this vulnerability aligns with CWE-835, Loop Without Reached Termination Condition, as the primary failure mode involves an infinite loop due to flawed termination logic. It also relates to CWE-400, Uncontrolled Resource Consumption, because the unbounded processing drains CPU resources excessively during packet dequeue operations. In terms of adversarial tactics, this exploit maps to ATT&CK technique T1529, System Shutdown or Reboot, as the resulting soft lockup effectively halts normal system operation and may require a hard reset if watchdogs do not automatically recover the state. Administrators should ensure that their systems are updated with kernel patches addressing these specific changes in net/sched/codel.c to prevent local denial of service attacks via traffic control misconfiguration.