CVE-2022-50174: net: hinic: avoid kernel hung in hinic_get_stats64()
In the Linux kernel, the following vulnerability has been resolved:
net: hinic: avoid kernel hung in hinic_get_stats64()
When using hinic device as a bond slave device, and reading device stats
of master bond device, the kernel may hung.
The kernel panic calltrace as follows:
Kernel panic - not syncing: softlockup: hung tasks
Call trace:
native_queued_spin_lock_slowpath+0x1ec/0x31c
dev_get_stats+0x60/0xcc
dev_seq_printf_stats+0x40/0x120
dev_seq_show+0x1c/0x40
seq_read_iter+0x3c8/0x4dc
seq_read+0xe0/0x130
proc_reg_read+0xa8/0xe0
vfs_read+0xb0/0x1d4
ksys_read+0x70/0xfc
__arm64_sys_read+0x20/0x30
el0_svc_common+0x88/0x234
do_el0_svc+0x2c/0x90
el0_svc+0x1c/0x30
el0_sync_handler+0xa8/0xb0
el0_sync+0x148/0x180
And the calltrace of task that actually caused kernel hungs as follows:
__switch_to+124
__schedule+548
schedule+72
schedule_timeout+348
__down_common+188
__down+24
down+104
hinic_get_stats64+44 [hinic]
dev_get_stats+92
bond_get_stats+172 [bonding]
dev_get_stats+92
dev_seq_printf_stats+60
dev_seq_show+24
seq_read_iter+964
seq_read+220
proc_reg_read+164
vfs_read+172
ksys_read+108
__arm64_sys_read+28
el0_svc_common+132
do_el0_svc+40
el0_svc+24
el0_sync_handler+164
el0_sync+324
When getting device stats from bond, kernel will call bond_get_stats().
It first holds the spinlock bond->stats_lock, and then call
hinic_get_stats64() to collect hinic device's stats.
However, hinic_get_stats64() calls `down(&nic_dev->mgmt_lock)` to
protect its critical section, which may schedule current task out.
And if system is under high pressure, the task cannot be woken up
immediately, which eventually triggers kernel hung panic.
Since previous patch has replaced hinic_dev.tx_stats/rx_stats with local
variable in hinic_get_stats64(), there is nothing need to be protected
by lock, so just removing down()/up() is ok.
Security readout for executives and security teams
Plain-English summary
CVE-2022-50174 is a Linux kernel availability issue involving Huawei HiNIC network devices used in bonding. Reading network statistics from the bonded interface can cause a kernel hang or panic under pressure. This is most relevant to servers using the hinic driver as a bond slave device.
Executive priority
Treat as a targeted availability risk for specific networked Linux servers, not a broad emergency. Prioritize infrastructure where bonded HiNIC adapters support critical services, because a kernel panic can interrupt service and require recovery.
Technical view
The flaw is in hinic_get_stats64(). bond_get_stats() holds bond->stats_lock, then calls hinic_get_stats64(), which used down(&nic_dev->mgmt_lock) and could sleep. Under high pressure this could trigger softlockup and hung-task panic. Kernel stable fixes remove the unnecessary lock around local stats handling.
Likely exposure
Exposure appears limited to Linux systems using the hinic driver with HiNIC hardware configured as a bonding slave. Systems without HiNIC hardware, without the hinic driver, or without bonding are unlikely to be affected based on the provided description.
Exploitation context
No active exploitation is reported in the provided sources, and the CVE is not marked KEV. The condition is triggered by reading bonded device statistics under high system pressure, causing denial of service rather than code execution.
Researcher notes
Severity, CVSS, and CWE are not provided in the source bundle. Affected version data is kernel-level and should be mapped through distro backports. The public fix rationale states the lock was unnecessary after prior stats handling changes.
Mitigation direction
Update to a vendor kernel that includes the referenced Linux stable fixes.
Prioritize servers using HiNIC adapters in bonded network configurations.
If patching is delayed, check vendor guidance; no temporary workaround is named in sources.
Schedule remediation carefully because kernel updates usually require reboot or live-patching support.
Validation and detection
Inventory Linux hosts with HiNIC hardware, hinic driver, and bonding enabled.
Compare running kernel packages against vendor advisories and referenced stable commits.
Review logs for softlockup, hung task, hinic_get_stats64, or bond_get_stats traces.
Confirm monitoring tools read interface statistics from bonded devices on affected hosts.
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-2022-50174 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
6Source 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.
Jun 18, 2025, 11:03 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.