CVE-2026-98957 in Linux
Summary
by MITRE • 10/23/2026
In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7915: disable rx napi when removing device
Unloading the mt7915e module with a MT7916 triggers multiples WARN in __netif_napi_del_locked() and in page_pool_disable_direct_recycling() because the driver does not disable the napi before destroying it.
This is troublesome since on MT7916 it is required to unload the module and reinsert it with a different enable_6ghz parameter to change the frequency. The system generally becomes unstable after reinserting the module.
Fix it by disabling rx napi inside mt7915e itself, even through napi rx is enabled in the mt76 generic code. Disabling it in the mt76 generic code was previously attempted and reverted because napi was disabled too late and rx handlers could access freed structures. Note that the tx side is enabled and disabled by the mt76 generic code.
It is disabled in mt7915_stop_hardware() since, unlike mt7915_unregister_device(), is it also called in the probe path if an error happens after rx napi is enabled.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/23/2026
The vulnerability identified within the Linux kernel's wireless networking subsystem involves a race condition and improper resource management sequence during the unloading of the MT7915e driver module, specifically when operating with MT7916 hardware. The core technical flaw lies in the failure to disable receive Network Interface Polling (NAPI) before initiating device destruction. When the mt7915e kernel module is unloaded while an MT7916 chip is active, the system triggers multiple warning messages originating from __netif_napi_del_locked() and page_pool_disable_direct_recycling(). These warnings indicate that NAPI structures are being removed without first ensuring that all pending receive operations have been safely halted. This oversight leads to a state where hardware interrupts or DMA transfers may still be attempting to write data into memory buffers that are in the process of being freed, creating a classic use-after-free scenario at the driver level.
The operational impact of this vulnerability is significant for system stability and network reliability. The issue manifests most critically when administrators attempt to reconfigure the wireless interface by unloading and reloading the module with different parameters, such as enabling or disabling 6GHz band support via the enable_6ghz flag. Because the driver does not properly quiesce the receive path before teardown, the subsequent reload often results in kernel instability, potential crashes, or unpredictable network behavior. This is particularly problematic for enterprise environments where dynamic reconfiguration of wireless access points may be required without a full system reboot. The presence of these warnings also indicates that memory management subsystems are detecting invalid states, which can lead to data corruption if the race condition allows hardware DMA writes to occur after buffer deallocation.
From a vulnerability classification perspective, this issue aligns with CWE-416: Use After Free, as the driver attempts to access or manage resources that may have been freed due to improper sequencing of cleanup routines. Additionally, it relates to CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization, since the NAPI poll mechanism and hardware interrupt handlers operate concurrently during module unload. In terms of MITRE ATT&CK mapping, this represents a weakness in resource management that could potentially be leveraged for denial-of-service attacks if an attacker can trigger repeated module reloads or exploit the race condition to cause kernel panics. The vulnerability is not directly exploitable for arbitrary code execution under normal circumstances but poses a severe risk to system availability and integrity through instability induced by routine administrative actions.
The resolution involves modifying the mt7915e driver to explicitly disable receive NAPI within its own cleanup logic, specifically inside the mt7915_stop_hardware() function. This approach was chosen over disabling NAPI in the generic mt76 code because previous attempts to do so resulted in timing issues where NAPI was disabled too late, allowing RX handlers to access freed structures during the window between disable and actual deallocation. By handling this within the specific driver implementation, developers ensure that receive processing is halted before any hardware resources are released. The tx side remains managed by the generic mt76 code as it does not present the same race condition risks in this context. Furthermore, placing the NAPI disable call in mt7915_stop_hardware() rather than mt7915_unregister_device() ensures that receive paths are also properly terminated during error handling paths in the probe sequence, preventing similar issues if initialization fails after RX NAPI has been enabled but before full device registration is complete.
To mitigate this vulnerability and prevent recurrence, system administrators should ensure they are running kernel versions where this patch is applied. For environments requiring frequent module reloading for configuration changes, it is advisable to verify that the driver version includes proper synchronization of hardware state transitions during unload operations. Developers maintaining custom kernels or out-of-tree drivers based on mt76 must review their cleanup sequences to ensure NAPI structures are disabled prior to any memory deallocation related to network interfaces. Regular auditing of kernel logs for WARN_ON messages in networking subsystems can help detect similar race conditions early, allowing for proactive remediation before they lead to system instability or security compromises.