CVE-2026-74698 in Linux
Summary
by MITRE • 08/22/2026
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: fix BQL reset on SQ re-activation
mlx5e_queue_start() deactivates and re-activates all channels but closes only the queue being restarted. mlx5e_activate_txqsq() then unconditionally calls netdev_tx_reset_queue(), zeroing the BQL counters of channels that kept their in-flight TX WQEs. The next completion then over-charges and trips the BUG_ON() in dql_completed():
kernel BUG at lib/dynamic_queue_limits.c:99! RIP: 0010:dql_completed+0x23d/0x280 Call Trace: <IRQ> mlx5e_poll_tx_cq+0x668/0xa60 mlx5e_napi_poll+0x5b/0x7b0 net_rx_action+0x15a/0x580
Reset BQL only when the SQ has no bytes in flight (sq->cc == sq->pc).
In the case that reset is skipped, the outstanding WQEs will eventually complete and rebalance the dql. The dql->limit is carried across the reset.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/22/2026
The vulnerability identified as CVE-2024-something related to the Mellanox mlx5e network driver in the Linux kernel represents a critical logic error within the Transmit Queue State Machine management, specifically affecting Byte Queue Limits (BQL) accounting during queue reactivation sequences. The core technical flaw resides in the interaction between the channel deactivation and activation phases of the transmit software queue structure. When the function mlx5e_queue_start is invoked to restart a specific send queue, it performs a broad operation that deactivates and subsequently re-activates all associated channels rather than isolating the state change strictly to the target queue being restarted. This architectural decision creates a window where the BQL accounting mechanism becomes desynchronized from the actual hardware ring buffer status because the driver fails to distinguish between queues that are genuinely idle and those that still hold in-flight Work Queue Elements (WQEs).
The immediate consequence of this logic error occurs when mlx5e_activate_txqsq executes an unconditional call to netdev_tx_reset_queue. This function is designed to reset BQL counters, effectively zeroing out the byte count for all active queues regardless of their actual transmission state. For channels that retained in-flight WQEs during the restart process, this action erroneously clears the recorded number of bytes currently pending hardware processing. Consequently, when these outstanding packets eventually complete and trigger a completion interrupt, the driver invokes dql_completed to update the dynamic queue limits based on the assumption that no bytes were previously accounted for. This results in an over-charge condition where the system believes more data has been transmitted than was actually present, leading to a severe accounting discrepancy.
This desynchronization triggers a fatal kernel panic via a BUG_ON assertion located within lib/dynamic_queue_limits.c at line 99. The call trace reveals that the crash originates from dql_completed being called with invalid state parameters derived from the erroneous reset. Specifically, the RIP instruction pointer indicates failure in the dynamic queue limit completion handler during an interrupt context handled by mlx5e_poll_tx_cq and subsequently mlx5e_napi_poll. This type of vulnerability is classified under CWE-682 Incorrect Calculation as it involves a fundamental error in state tracking logic that leads to memory safety violations or kernel instability through assertion failures rather than traditional buffer overflows. From an ATT&CK perspective, this aligns with T1499 Endpoint Denial of Service due to the potential for local denial of service via triggerable kernel crashes if an attacker can induce repeated queue restart conditions under load.
The operational impact of this vulnerability is significant as it compromises system stability and availability on systems utilizing Mellanox ConnectX adapters running affected Linux kernels. A successful exploitation scenario does not necessarily require remote code execution but rather the ability to trigger network traffic patterns that cause frequent transmit queue resets while data remains in flight. This could be achieved through high-throughput workloads or specific packet scheduling configurations that stress the NAPI polling mechanism. The resulting kernel panic leads to an immediate system crash, requiring a reboot and causing downtime for any services hosted on the affected machine. In virtualized environments where multiple VMs share physical NIC resources via SR-IOV, this instability could potentially impact other tenants depending on how the hypervisor handles host-level crashes or resets associated with the PF driver failure.
To mitigate this vulnerability, system administrators must apply the upstream kernel patch that modifies the BQL reset logic to be conditional rather than unconditional. The fix ensures that netdev_tx_reset_queue is only invoked when the send queue has no bytes in flight, verified by checking if the completion counter equals the producer counter (sq->cc == sq->pc). This preserves the integrity of the dynamic queue limits for queues still processing packets. Until a patched kernel version is deployed, operators should monitor system logs for dql_completed assertions and consider reducing network throughput or adjusting interrupt coalescing settings to minimize the frequency of queue restarts during high-load periods. Long-term remediation involves ensuring that all Mellanox-enabled systems are updated to include this specific fix in their net/mlx5e driver components, thereby restoring correct BQL accounting behavior and preventing kernel panics associated with transmit queue state management errors.