CVE-2023-54000: net: hns3: fix deadlock issue when externel_lb and reset are executed together
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().
Security readout for executives and security teams
Plain-English summary
CVE-2023-54000 is a Linux kernel availability bug in the hns3 network driver. If external loopback handling and a reset run together, the driver can deadlock and leave kernel work blocked. The public sources do not show active exploitation or a CVSS score.
Executive priority
Treat this as targeted availability risk, not broad emergency exposure. Prioritize patching where affected hns3-driven network interfaces support production services, especially high-availability or network-sensitive systems.
Technical view
The hns3 driver may call napi_disable() during external_lb, then hit a reset path that prevents the matching napi_enable(). A later external_lb can double-call napi_disable(), contributing to rtnl_lock deadlock. The kernel fix uses HNS3_NIC_STATE_DOWN to guard napi_disable()/napi_enable() calls.
Likely exposure
Exposure appears limited to Linux systems using the hns3 driver on affected kernel builds. Fleets without this driver or hardware are unlikely to be exposed. The bundle’s affected-version data is incomplete, so confirm against distro advisories and kernel package changelogs.
Exploitation context
The sources describe a concurrency deadlock, not remote code execution. No KEV listing is present, and the bundle provides no evidence of active exploitation. Trigger conditions require external_lb and reset occurring together, suggesting an availability issue in a specific driver path.
Researcher notes
The key evidence is the kernel commit description and CVE record. The affected-version list in the bundle is not fully normalized, and no CVSS, CWE, exploit, or distro-specific package data is provided. Avoid overgeneralizing beyond hns3 driver exposure.
Mitigation direction
Identify Linux hosts loading or packaging the hns3 driver.
Apply vendor or distro kernel updates containing the referenced stable fixes.
Prioritize hosts where hns3 NICs support critical network paths.
Avoid unnecessary external loopback testing on affected systems until patched.
Check kernel vendor guidance for backported fixes and package names.
Validation and detection
Confirm current kernel version and distro backport status.
Check whether hns3 or hclge modules are present or loaded.
Review kernel logs for blocked hclge_service_task or rtnl_lock deadlock messages.
Map installed kernels against vendor advisories and referenced stable commits.
After patching, verify the updated kernel is booted.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2023-54000 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
0CVSS vectors
3Timeline events
0ADP providers
5Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
Dec 24, 2025, 10:55 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.