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).
https://git.kernel.org/stable/c/f6c1aad9b35fa083f48ce0c5926204891d82e089
https://git.kernel.org/stable/c/c4cb9a728df66c46067b26263f5beb633aae4087
https://git.kernel.org/stable/c/7c5d41f87f079990bf241359e3c1332d8d10fe87