CVE-2026-98574 in Linux
Summary
by MITRE • 10/18/2026
In the Linux kernel, the following vulnerability has been resolved:
net: bcmgenet: stop Tx NAPI before disabling the queues
bcmgenet_netif_stop() and the Wake-on-LAN branch of bcmgenet_suspend() both disable the Tx queues first and stop Tx NAPI several steps later. A completion in flight calls netif_tx_wake_queue() in between, and nothing stops the queue again, so a transmit can reach the rings after they have been freed.
Close is safe because dev_deactivate_many() stops the qdisc first. bcmgenet_suspend() does not, so stop Tx NAPI before the queues on both paths.
KASAN on a Raspberry Pi CM4, driven from an MTU change because suspend freezes user space before the callback runs:
BUG: KASAN: use-after-free in bcmgenet_xmit+0x17f8/0x2258 Write of size 8 at addr ffffff8055844a68 by task ksoftirqd/0/14 bcmgenet_xmit+0x17f8/0x2258 dev_hard_start_xmit+0x13c/0x588 sch_direct_xmit+0x108/0x340 __dev_queue_xmit+0x1190/0x3848
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/18/2026
The vulnerability identified in the Linux kernel network driver bcmgenet involves a critical race condition during device suspension and queue management, specifically within the Broadcom GENET Ethernet controller. This issue stems from an incorrect ordering of operations when stopping transmission queues and disabling Network API (NAPI) polling mechanisms. In normal operation, the function bcmgenet_netif_stop is responsible for halting network traffic by first disabling transmit queues and subsequently stopping Tx NAPI to prevent further packet processing interrupts. Similarly, during system suspend cycles managed by bcmgenet_suspend, the driver attempts to prepare the hardware for low-power states by also managing these transmission resources. However, both code paths exhibit a flaw where they disable the transmit queues before explicitly stopping the associated Tx NAPI context. This sequence creates a dangerous window of opportunity for race conditions that can lead to memory corruption and system instability.
The core technical flaw lies in the timing between queue deactivation and interrupt handling suppression. When the transmit queues are disabled, existing packets or completions already in flight may still trigger callbacks. Specifically, a completion handler might invoke netif_tx_wake_queue, which re-enables the transmission path even though the driver intends to shut it down completely. Because Tx NAPI has not yet been stopped at this moment, the hardware interrupt handling remains active and capable of processing new transmit descriptors. Consequently, if a packet is queued during this interval after the queues have logically been marked as stopped but before NAPI is disabled, the transmission logic may proceed to access memory buffers that are no longer valid. This situation arises because the driver frees or reuses buffer rings while assuming they are protected from further access by the halted state of the network interface.
This race condition results in a use-after-free vulnerability, as evidenced by Kernel Address Sanitizer (KASAN) reports on hardware platforms such as the Raspberry Pi Compute Module 4. The KASAN output indicates a write operation occurring within bcmgenet_xmit at an address that has already been freed. This occurs because dev_hard_start_xmit and subsequent queuing functions like sch_direct_xmit are invoked via __dev_queue_xmit, which can be triggered by internal kernel tasks such as ksoftirqd during MTU changes or suspend transitions. The freeze of user space before the suspend callback fully executes exacerbates this issue, allowing pending network operations to persist in a state where the underlying driver resources have been deallocated but not properly isolated from interrupt-driven access paths.
The operational impact of this vulnerability is severe, potentially leading to kernel panics, data corruption, or arbitrary code execution if an attacker can influence the timing of these race conditions through crafted network traffic or system power management triggers. The use-after-free nature means that freed memory regions may be overwritten with malicious payloads, compromising the integrity and confidentiality of the host system. In embedded environments like those using Raspberry Pi hardware, this could result in device bricking or loss of connectivity during critical suspend-resume cycles, affecting reliability for IoT applications or always-on network appliances.
To mitigate this vulnerability, the fix involves reordering the operations within bcmgenet_netif_stop and bcmgenet_suspend to ensure that Tx NAPI is stopped before transmit queues are disabled. This ensures that no new interrupts can trigger packet processing after the decision has been made to halt transmission activity. By stopping NAPI first, any in-flight completions are processed without re-enabling queue access, thereby preventing subsequent packets from reaching freed rings. For systems running affected kernel versions, applying the latest upstream Linux kernel patches is essential. Administrators should also monitor for KASAN reports during suspend operations and consider disabling Wake-on-LAN features if they trigger frequent suspends until updates are applied.
From a classification perspective, this vulnerability aligns with CWE-416: Use After Free, as it involves accessing memory after it has been freed due to improper synchronization of resource lifecycle management. It also relates to CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization, highlighting the failure to properly serialize access between interrupt handlers and driver state changes. In terms of MITRE ATT&CK mapping, this could be associated with T1059: Command and Scripting Interpreter if exploited for initial execution via kernel exploitation techniques, or more broadly under Defense Evasion tactics where attackers leverage race conditions in system drivers to bypass security controls. Maintaining strict adherence to driver API conventions regarding queue stopping order is crucial for preventing similar issues across other network subsystems within the Linux kernel architecture.