CVE-2026-97411 in Linux
Summary
by MITRE • 09/24/2026
In the Linux kernel, the following vulnerability has been resolved:
net: ibm: emac: mal: fix potential system hang in mal_remove()
napi_disable() is not idempotent and calling it on an already-disabled or unenabled NAPI context will cause the kernel to spin indefinitely waiting for the NAPI_STATE_SCHED bit to clear.
In mal_remove(), napi_disable() is called unconditionally. If no MACs were registered, NAPI was never enabled. Also, if they were registered but subsequently unregistered, NAPI was already disabled in mal_unregister_commac(). In either case, calling napi_disable() causes the kernel to hang upon module removal.
Fix this by only calling napi_disable() in mal_remove() if the commac list is not empty (which implies NAPI is enabled).
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/24/2026
The Linux kernel network subsystem contains a critical flaw within the IBM eMAC driver, specifically in the media access layer remove function known as mal_remove. This vulnerability stems from an improper handling of the Network API context state during module unloading or device removal operations. The core issue lies in the unconditional invocation of napi_disable without verifying whether NAPI was previously enabled for the specific communication controller instance. In Linux kernel networking, NAPI is a mechanism designed to improve network performance by switching between interrupt-driven and polling-based packet processing. However, the API functions governing this state are not idempotent regarding their preconditions. Specifically, calling napi_disable on a context that has never been started or has already been disabled leads to an infinite loop where the kernel waits indefinitely for the NAPI_STATE_SCHED bit to clear, resulting in a complete system hang rather than a graceful shutdown.
The technical root cause is located in the logic flow of mal_remove which serves as the cleanup routine when the driver module is unloaded or hardware is removed from the bus. The function attempts to disable polling and clean up resources by calling napi_disable on all registered communication controllers. However, it fails to check if any MACs were ever successfully registered for that instance. If no MACs were registered during initialization, NAPI was never enabled via napi_enable, meaning its internal state remains in a disabled or uninitialized condition. Similarly, if the device was previously unregistered through mal_unregister_commac, the NAPI context would have already been explicitly disabled at that time. In both scenarios, invoking napi_disable again violates the expected state machine transitions of the kernel networking stack. The function enters a tight spin loop waiting for a flag change that will never occur because the scheduler bit is not set in an unstarted or already-disabled context.
The operational impact of this vulnerability is severe, primarily manifesting as a denial of service through system instability. When triggered during module removal, typically via rmmod commands or hot-unplug events on affected hardware platforms such as IBM PowerPC systems utilizing eMAC controllers, the kernel hangs indefinitely. This renders the entire operating system unresponsive to further input and requires a hard reset to recover. While this does not allow for remote code execution or privilege escalation in its current form, it poses significant risks to system availability, particularly in environments where drivers are frequently loaded and unloaded during development, testing, or dynamic configuration changes. The lack of idempotency means that any script or automated process attempting to reload the driver will likely freeze the host machine if cleanup routines do not properly track state transitions.
To mitigate this vulnerability, developers must ensure that resource deallocation functions strictly adhere to the lifecycle states of their components. In this specific case, the fix involves modifying mal_remove to check whether the commac list is non-empty before attempting to disable NAPI. This conditional check ensures that napi_disable is only called when there is an active context that was previously enabled and requires shutdown. This aligns with best practices for driver development where state tracking variables should be maintained throughout the device lifecycle to prevent double-free or invalid-state operations. Furthermore, this incident highlights a broader category of issues related to improper resource management in kernel modules.
From a classification perspective, this vulnerability maps directly to CWE-823 which describes use of outdated or incorrect API calls that lead to unexpected behavior. It also relates to CWE-401 regarding missing release of memory after effective ownership transfer, although here the consequence is state corruption rather than leak. In terms of adversarial tactics, while primarily a stability issue, such bugs can be leveraged in local denial-of-service attacks within ATT&CK framework techniques related to resource exhaustion or system availability disruption. Security auditors and kernel maintainers should review similar drivers for analogous patterns where cleanup routines assume prior successful initialization without verification. Ensuring that all teardown paths are idempotent or state-aware is crucial for maintaining the robustness of the Linux networking stack against accidental crashes during administrative operations.