CVE-2025-22010 Overview
CVE-2025-22010 is a Linux kernel vulnerability in the HiSilicon Network Subsystem RDMA over Converged Ethernet (RoCE) driver (hns_roce_hw_v2). The driver runs a for-loop when allocating base table (BT) pages and mapping them with buffer pages. When a large memory region (MR) over 100GB is allocated, the loop count becomes large enough to trigger a soft lockup. The watchdog reports CPUs stuck for more than 20 seconds inside hem_list_alloc_mid_bt and hns_roce_hem_list_find_mtt. The defect is classified as [CWE-667] Improper Locking and affects multiple Linux kernel versions including 6.14 release candidates.
Critical Impact
A local authenticated user can trigger CPU soft lockups and host-level availability degradation by registering very large memory regions through ib_uverbs_reg_mr.
Affected Products
- Linux Kernel (multiple stable branches prior to fix)
- Linux Kernel 6.14-rc1 through 6.14-rc7
- Debian LTS distributions shipping the hns_roce_hw_v2 driver
Discovery Timeline
- 2025-04-08 - CVE-2025-22010 published to NVD
- 2025-11-03 - Last updated in NVD database
Technical Details for CVE-2025-22010
Vulnerability Analysis
The vulnerability resides in the hns_roce_hw_v2 InfiniBand driver, which provides RDMA support for HiSilicon network adapters. When user space calls ib_uverbs_reg_mr to register a memory region, the driver invokes hns_roce_reg_user_mr, which in turn calls alloc_mr_pbl and hns_roce_mtr_create to allocate the Memory Translation Region (MTR) structures.
Inside hns_roce_hem_list_request, the function hem_list_alloc_mid_bt iterates to allocate intermediate base table pages and link them to buffer pages. A similar uninterrupted loop runs in hns_roce_hem_list_find_mtt during mtr_map_bufs. For memory regions larger than 100GB, these loops execute long enough to prevent the scheduler from running on the affected CPU, causing the kernel watchdog to fire a soft lockup warning.
Root Cause
The root cause is the absence of voluntary preemption points inside the BT page allocation and MTT lookup loops. The driver holds the CPU for the full duration of the allocation without yielding, which violates expectations for long-running kernel code paths. The fix introduces a cond_resched() call gated on a loop-count threshold tuned to a 100GB MR, preserving performance for normal allocations while allowing the scheduler to run during large ones.
Attack Vector
Exploitation requires local access with permission to open an RDMA user-verbs device node and register memory regions on a host equipped with an HNS RoCE adapter. By repeatedly registering oversized memory regions, a local user can hang individual CPUs, degrade host responsiveness, and impair other workloads sharing the system. The issue does not allow code execution or data disclosure.
// No verified exploit code is available for CVE-2025-22010.
// The defect is triggered through normal RDMA user-verbs API calls
// with abnormally large memory region sizes (>100GB), reaching:
// ib_uverbs_reg_mr -> hns_roce_reg_user_mr -> alloc_mr_pbl
// -> hns_roce_mtr_create -> hns_roce_hem_list_request
// -> hem_list_alloc_mid_bt (soft lockup site)
Detection Methods for CVE-2025-22010
Indicators of Compromise
- Kernel log entries containing watchdog: BUG: soft lockup - CPU#N stuck for Ns! with call traces referencing hem_list_alloc_mid_bt or hns_roce_hem_list_find_mtt.
- Repeated ib_uverbs_reg_mr calls from a single non-privileged user registering memory regions larger than 100GB.
- Sudden CPU stalls correlated with RDMA workload startup on hosts using the hns_roce_hw_v2 driver.
Detection Strategies
- Parse dmesg and /var/log/messages for soft lockup traces that include the hns_roce_hw_v2 module name.
- Audit kernel module inventory to identify hosts that load hns_roce_hw_v2 and validate they are running a patched kernel.
- Correlate RDMA verbs telemetry with CPU stall events to identify users registering oversized memory regions.
Monitoring Recommendations
- Forward kernel ring buffer and journald logs to a centralized log platform and alert on the soft lockup string.
- Track /proc/loadavg and per-CPU run-queue metrics to identify hosts that exhibit sustained single-CPU saturation.
- Monitor InfiniBand verbs usage via rdma tooling to baseline normal MR sizes per workload.
How to Mitigate CVE-2025-22010
Immediate Actions Required
- Inventory all Linux hosts running the hns_roce_hw_v2 driver and prioritize patching those exposed to multi-tenant or untrusted local users.
- Apply the stable kernel updates referenced by the upstream fix commits or vendor advisories before resuming large RDMA workloads.
- Restrict access to /dev/infiniband/uverbs* device nodes to trusted service accounts using filesystem permissions or cgroup device controllers.
Patch Information
The fix adds a cond_resched() call inside the BT page allocation loop, gated on a threshold corresponding to a 100GB memory region. Stable kernel commits include Kernel Git Commit 13a52f6, Kernel Git Commit 25655580, Kernel Git Commit 4104b002, Kernel Git Commit 975355fa, and Kernel Git Commit 9ab20fec. Debian users should apply updates from Debian LTS Announcement 30 and Debian LTS Announcement 45.
Workarounds
- Unload the hns_roce_hw_v2 module on hosts that do not require HNS RDMA functionality using modprobe -r hns_roce_hw_v2.
- Constrain user-space RDMA consumers with cgroups and resource limits to cap the maximum memory region size they can register.
- Limit access to RDMA verbs device nodes to administrative users until the patched kernel is deployed.
# Verify whether the vulnerable driver is loaded
lsmod | grep hns_roce_hw_v2
# Check current kernel version and confirm patch level against vendor advisory
uname -r
# Restrict access to InfiniBand user-verbs device nodes
chgrp rdma /dev/infiniband/uverbs*
chmod 660 /dev/infiniband/uverbs*
# Search for soft lockup traces tied to the vulnerable code path
dmesg | grep -E 'soft lockup|hns_roce'
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
