CVE-2023-54000
NoneCVSS
—
EPSS
0.2%
Published
Dec 24, 2025
CISA due date
—
Cloudanix analysis
A timing problem in certain network card handling can freeze parts of the system when two maintenance tasks run at the same time.
- Exploitation
- Local Privilege
- Attacker needs
- Low Privilege
- Complexity
- Moderate
- Impact
- Denial Of Service
- Component
- OS kernel
- Class
- Race Condition
- Remediation
- Patch
- Effort
- Medium
- Patch risk
- Low
What it actually does
Race condition between external loopback and reset paths allows napi_disable to be invoked twice without an intervening napi_enable, causing the second caller to block indefinitely on rtnl_lock.
Why it matters to the business
Network interface resets or diagnostics can hang the system for extended periods, disrupting connectivity and requiring manual intervention or reboot; low exploitability reduces immediate risk but still affects reliability of affected network hardware.
How an attack unfolds
An attacker with local access triggers concurrent external_lb and reset operations on the hns3 device; the resulting double napi_disable call deadlocks rtnl_lock, blocking the service task and any dependent network operations.
How to fix it
Apply the upstream fix that guards napi_disable/enable calls with the HNS3_NIC_STATE_DOWN state flag, equivalent to the protection already used in ndo_stop/ndo_start; update to a kernel containing commit resolving CVE-2023-54000.
How to confirm the fix worked
Confirm the HNS3_NIC_STATE_DOWN guard is present around external_lb napi calls; test concurrent external_lb and reset sequences to verify absence of deadlock and hung-task warnings.
Typical attack path
- Obtain local access or trigger diagnostic/reset paths on hns3 hardware
- Simultaneously invoke external loopback and device reset operations
- Trigger the unprotected napi_disable sequence leading to mutex acquisition failure
- Cause prolonged task blocking and service degradation
How to detect it
Search kernel logs for hung-task timeouts exceeding 120 seconds involving kworker threads in hclge and stack traces showing mutex_lock on rtnl_lock during hclge_reset_prepare; look for repeated external_lb operations followed by reset events.
What your security team should do
- Prioritize kernel updates containing the state-guard fix on all systems using hns3 hardware
- Monitor for hung-task reports referencing hclge_service_task or rtnl_lock in logs
- Restrict unprivileged access to network diagnostic and reset interfaces until patched
The record
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().
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|---|---|---|
| Linux | Kernel | 6.1.0 | 6.1.46 |
| SUSE:Linux Enterprise High Availability Extension 15 SP6 | kernel-default | 0 | 6.4.0-150600.23.84.1 |
| SUSE:Linux Enterprise Live Patching 15 SP6 | kernel-default | 0 | 6.4.0-150600.23.84.1 |
| SUSE:Linux Enterprise Live Patching 15 SP6 | kernel-livepatch-SLE15-SP6_Update_19 | 0 | 1-150600.13.3.1 |
| SUSE:Linux Enterprise Server 15 SP6-LTSS | kernel-64kb | 0 | 6.4.0-150600.23.84.1 |
| SUSE:Linux Enterprise Server 15 SP6-LTSS | kernel-default | 0 | 6.4.0-150600.23.84.1 |
| SUSE:Linux Enterprise Server 15 SP6-LTSS | kernel-default-base | 0 | 6.4.0-150600.23.84.1.150600.12.38.1 |
| SUSE:Linux Enterprise Server 15 SP6-LTSS | kernel-docs | 0 | 6.4.0-150600.23.84.1 |
| SUSE:Linux Enterprise Server 15 SP6-LTSS | kernel-obs-build | 0 | 6.4.0-150600.23.84.1 |
| SUSE:Linux Enterprise Server 15 SP6-LTSS | kernel-source | 0 | 6.4.0-150600.23.84.1 |
| SUSE:Linux Enterprise Server 15 SP6-LTSS | kernel-syms | 0 | 6.4.0-150600.23.84.1 |
| SUSE:Linux Enterprise Server 15 SP6-LTSS | kernel-zfcpdump | 0 | 6.4.0-150600.23.84.1 |
| SUSE:Linux Enterprise Server for SAP Applications 15 SP6 | kernel-default | 0 | 6.4.0-150600.23.84.1 |
| SUSE:Linux Enterprise Server for SAP Applications 15 SP6 | kernel-default-base | 0 | 6.4.0-150600.23.84.1.150600.12.38.1 |
| SUSE:Linux Enterprise Server for SAP Applications 15 SP6 | kernel-docs | 0 | 6.4.0-150600.23.84.1 |
| SUSE:Linux Enterprise Server for SAP Applications 15 SP6 | kernel-obs-build | 0 | 6.4.0-150600.23.84.1 |
| SUSE:Linux Enterprise Server for SAP Applications 15 SP6 | kernel-source | 0 | 6.4.0-150600.23.84.1 |
| SUSE:Linux Enterprise Server for SAP Applications 15 SP6 | kernel-syms | 0 | 6.4.0-150600.23.84.1 |
| openSUSE:Leap 15.6 | dtb-aarch64 | 0 | 6.4.0-150600.23.84.1 |
| openSUSE:Leap 15.6 | kernel-64kb | 0 | 6.4.0-150600.23.84.1 |
| openSUSE:Leap 15.6 | kernel-debug | 0 | 6.4.0-150600.23.84.1 |
| openSUSE:Leap 15.6 | kernel-default | 0 | 6.4.0-150600.23.84.1 |
| openSUSE:Leap 15.6 | kernel-default-base | 0 | 6.4.0-150600.23.84.1.150600.12.38.1 |
| openSUSE:Leap 15.6 | kernel-docs | 0 | 6.4.0-150600.23.84.1 |
| openSUSE:Leap 15.6 | kernel-kvmsmall | 0 | 6.4.0-150600.23.84.1 |
| openSUSE:Leap 15.6 | kernel-obs-build | 0 | 6.4.0-150600.23.84.1 |
| openSUSE:Leap 15.6 | kernel-obs-qa | 0 | 6.4.0-150600.23.84.1 |
| openSUSE:Leap 15.6 | kernel-source | 0 | 6.4.0-150600.23.84.1 |
| openSUSE:Leap 15.6 | kernel-syms | 0 | 6.4.0-150600.23.84.1 |
| openSUSE:Leap 15.6 | kernel-zfcpdump | 0 | 6.4.0-150600.23.84.1 |
Related vulnerabilities
- CVE-2026-23226 In the Linux kernel, the following vulnerability has been resolved: ksmbd: add chann_lock… Also affects Kernel
- CVE-2026-23225 In the Linux kernel, the following vulnerability has been resolved: sched/mmcid: Don't… Also affects Kernel
- CVE-2026-23230 In the Linux kernel, the following vulnerability has been resolved: smb: client: split… Also affects Kernel
- CVE-2026-23224 In the Linux kernel, the following vulnerability has been resolved: erofs: fix UAF issue… Also affects Kernel
- CVE-2026-23227 In the Linux kernel, the following vulnerability has been resolved: drm/exynos: vidi: use… Also affects Kernel
- CVE-2026-23223 In the Linux kernel, the following vulnerability has been resolved: xfs: fix UAF in… Also affects Kernel
- CVE-2026-23228 In the Linux kernel, the following vulnerability has been resolved: smb: server: fix leak… Also affects Kernel
- CVE-2026-23229 In the Linux kernel, the following vulnerability has been resolved: crypto: virtio - Add… Also affects Kernel