CVE-2026-97411: net: ibm: emac: mal: fix potential system hang in mal_remove()
In the Linux kernel, the following vulnerability has been resolved:
net: ibm: emac: mal: fix potential system hang in malremove()
napidisable() is not idempotent and calling it on an already-disabled or unenabled NAPI context will cause the kernel to spin indefinitely waiting for the NAPISTATESCHED bit to clear.
In malremove(), napidisable() 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 malunregistercommac(). In either case, calling napidisable() causes the kernel to hang upon module removal.
Fix this by only calling napidisable() in malremove() if the commac list is not empty (which implies NAPI is enabled).
Affected Software
Event History
Frequently Asked Questions
When can this issue cause a system hang?
The hang occurs during removal of the MAL module when mal_remove() calls napi_disable() on a NAPI context that was never enabled or was already disabled. This can happen if no MACs were registered, or if registered MACs were later unregistered.
What is required to trigger the affected code path?
The MAL module must be removed while its commac list is empty. An empty list indicates that NAPI is not enabled, making the unconditional napi_disable() call unsafe.
How can I determine whether a system is exposed to this condition?
A system is exposed if it uses the affected MAL driver and may remove its module after no MACs have been registered or after all previously registered MACs have been unregistered. The observable symptom is an indefinite kernel hang during module removal.
What is the mitigation when an updated kernel is not immediately available?
Avoid removing the MAL module when its commac list is empty. In particular, do not unload it after all MACs have been unregistered or when no MACs were ever registered.