CVE-2023-54000 in Linux
Summary
by MITRE • 12/24/2025
In the Linux kernel, the following vulnerability has been resolved:
net: hns3: fix deadlock issue when externel_lb and reset are executed together
When externel_lb and reset are executed together, a deadlock may occur: [ 3147.217009] INFO: task kworker/u321:0:7 blocked for more than 120 seconds.
[ 3147.230483] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 3147.238999] task:kworker/u321:0 state:D stack: 0 pid: 7 ppid: 2 flags:0x00000008
[ 3147.248045] Workqueue: hclge hclge_service_task [hclge]
[ 3147.253957] Call trace:
[ 3147.257093] __switch_to+0x7c/0xbc
[ 3147.261183] __schedule+0x338/0x6f0
[ 3147.265357] schedule+0x50/0xe0
[ 3147.269185] schedule_preempt_disabled+0x18/0x24
[ 3147.274488] __mutex_lock.constprop.0+0x1d4/0x5dc
[ 3147.279880] __mutex_lock_slowpath+0x1c/0x30
[ 3147.284839] mutex_lock+0x50/0x60
[ 3147.288841] rtnl_lock+0x20/0x2c
[ 3147.292759] hclge_reset_prepare+0x68/0x90 [hclge]
[ 3147.298239] hclge_reset_subtask+0x88/0xe0 [hclge]
[ 3147.303718] hclge_reset_service_task+0x84/0x120 [hclge]
[ 3147.309718] hclge_service_task+0x2c/0x70 [hclge]
[ 3147.315109] process_one_work+0x1d0/0x490
[ 3147.319805] worker_thread+0x158/0x3d0
[ 3147.324240] kthread+0x108/0x13c
[ 3147.328154] ret_from_fork+0x10/0x18
In externel_lb process, the hns3 driver call napi_disable() first, then the reset happen, then the restore process of the externel_lb will fail, and will not call napi_enable(). When doing externel_lb again, napi_disable() will be double call, cause a deadlock of rtnl_lock().
This patch use the HNS3_NIC_STATE_DOWN state to protect the calling of napi_disable() and napi_enable() in externel_lb process, just as the usage in ndo_stop() and ndo_start().
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 01/30/2026
The vulnerability CVE-2023-54000 affects the Linux kernel's hns3 network driver, specifically impacting the Huawei SmartNIC HNS3 family of network interface controllers. This issue manifests as a deadlock condition that occurs when external loopback operations and reset operations are executed concurrently. The problem stems from improper synchronization mechanisms within the driver's handling of network interface state transitions, creating a scenario where the routing netlink lock becomes indefinitely blocked.
The technical flaw involves a race condition between the external loopback configuration process and the network reset operation. During external loopback setup, the driver invokes napi_disable() to disable network interrupt handling, but if a reset operation occurs concurrently, the restore process fails to call napi_enable() properly. This failure creates a state where napi_disable() is called twice without corresponding napi_enable() calls, leading to a deadlock on the rtnl_lock mutex. The kernel log trace shows the kworker thread blocked for over 120 seconds, indicating the severity of the lock contention that prevents normal system operation.
The operational impact of this vulnerability is significant for systems utilizing Huawei SmartNICs in production environments where network reliability is critical. The deadlock condition can cause complete network interface unavailability, forcing system administrators to perform manual reboots or manual intervention to restore network functionality. This vulnerability particularly affects data center and high-performance computing environments where network stability is paramount, as it can lead to service disruption and potential data loss during critical operations.
The fix implemented addresses this issue by introducing proper state management using the HNS3_NIC_STATE_DOWN state flag to protect calls to napi_disable() and napi_enable() during external loopback operations. This approach mirrors the established patterns used in the driver's ndo_stop() and ndo_start() methods, ensuring consistent state management across different network interface operations. The solution follows established kernel development practices and aligns with CWE-362, which addresses race conditions and improper locking mechanisms that can lead to deadlocks. This mitigation strategy ensures that network interface state transitions are properly synchronized and prevents the double invocation of napi_disable() that was causing the deadlock condition.
This vulnerability demonstrates the importance of proper synchronization in kernel network drivers and highlights how seemingly simple operations can create complex deadlock scenarios when concurrent operations are not properly coordinated. The fix represents a defensive programming approach that prevents improper state transitions during critical network operations, aligning with ATT&CK technique T1490 for denial of service through system resource exhaustion. The solution emphasizes the need for robust state management in kernel modules, particularly for hardware drivers that must handle concurrent operations from multiple system components while maintaining network availability and system stability.