CVE-2025-22010: Linux Kernel RDMA/hns DoS Vulnerability

CVE-2025-22010 Overview

CVE-2025-22010 is a Denial of Service vulnerability in the Linux kernel's RDMA/hns (Remote Direct Memory Access for HiSilicon Network Subsystem) driver. The vulnerability occurs during the allocation and mapping of bt (buffer table) pages with buffer pages in the hem_list_alloc_mid_bt and related functions. When allocating large memory regions (e.g., MR over 100GB), the driver enters a prolonged for-loop that fails to yield CPU time, triggering the kernel's soft lockup watchdog mechanism.

Critical Impact

This vulnerability enables local attackers to cause system availability issues by triggering soft lockups that can freeze affected CPUs for extended periods, potentially leading to system instability or denial of service conditions.

Affected Products

• Linux Kernel versions prior to patched releases
• Linux Kernel 6.14 Release Candidates (rc1 through rc7)
• Systems utilizing HiSilicon RDMA network adapters with hns_roce_hw_v2 driver

Discovery Timeline

• 2025-04-08 - CVE 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 HiSilicon RDMA driver's memory management subsystem, specifically within the hardware memory (HEM) list allocation functions. When a user requests registration of a large memory region through the ib_uverbs_reg_mr interface, the kernel driver allocates and maps bt pages to buffer pages in a tight loop. For memory regions exceeding 100GB, this loop requires an extensive number of iterations without any scheduling breaks, causing the CPU to become stuck in kernel space.

The kernel's watchdog mechanism detects this condition and reports soft lockups, with observed stuck times of 22-23 seconds on affected CPUs. The call traces show the issue occurring in two related code paths: hem_list_alloc_mid_bt during allocation and hns_roce_hem_list_find_mtt during the mapping phase.

Root Cause

The root cause is a missing cond_resched() call within the for-loops responsible for bt page allocation and buffer mapping in the RDMA/hns driver. The cond_resched() function is a kernel mechanism that allows other processes to execute during long-running kernel operations, preventing the soft lockup condition. Without this cooperative scheduling point, the kernel scheduler cannot preempt the long-running loop, triggering the watchdog detector.

The fix implements cond_resched() calls within these loops, using the loop count equivalent to a 100GB MR as the threshold to trigger the reschedule. This approach maintains allocation performance for normal-sized buffers while preventing lockups during large allocations.

Attack Vector

The vulnerability requires local access to the system with the ability to interact with the RDMA subsystem through the verbs interface. An attacker would need:

1. Local access to a system with HiSilicon RDMA hardware and the hns_roce_hw_v2 kernel module loaded
2. Permissions to register memory regions through the InfiniBand verbs interface (ib_uverbs)
3. The ability to request allocation of very large memory regions (100GB or more)

By submitting a memory registration request for an exceptionally large buffer through ib_uverbs_reg_mr, an attacker can trigger the soft lockup condition. While this requires local access and specific hardware, it could be exploited in multi-tenant environments where RDMA access is provided to untrusted users, or as part of a larger attack chain.

Detection Methods for CVE-2025-22010

Indicators of Compromise

• Kernel log messages indicating "BUG: soft lockup - CPU#XX stuck for XXs!" with call traces pointing to hns_roce_hw_v2 module functions
• System unresponsiveness or degraded performance coinciding with RDMA memory registration operations
• Watchdog timer alerts and NMI watchdog reports in system logs
• Elevated CPU utilization locked to 100% on specific cores during RDMA operations

Detection Strategies

• Monitor kernel logs (dmesg, /var/log/kern.log) for soft lockup warnings referencing hem_list_alloc_mid_bt, hns_roce_hem_list_find_mtt, or hns_roce_mtr_create functions
• Implement alerting on watchdog events that include the hns_roce_hw_v2 module in their call traces
• Track large memory region registration requests through RDMA subsystem auditing mechanisms
• Deploy kernel tracing (ftrace, eBPF) to monitor unusual patterns in the ib_uverbs_reg_mr path

Monitoring Recommendations

• Enable and configure the kernel watchdog with appropriate thresholds and alerting for soft lockup detection
• Implement resource limits on RDMA memory region sizes to prevent abuse of large allocation requests
• Use SentinelOne's Linux agent to monitor for anomalous kernel behavior and denial of service patterns
• Review audit logs for unusual RDMA verbs interface access patterns from non-privileged users

How to Mitigate CVE-2025-22010

Immediate Actions Required

• Apply the kernel patches from the official Linux kernel stable branches immediately
• Review and restrict access to RDMA subsystem interfaces to authorized applications only
• Monitor systems for signs of exploitation while awaiting patch deployment
• Consider temporarily limiting memory region size capabilities if patching is delayed

Patch Information

The vulnerability has been addressed through multiple commits to the Linux kernel stable branches. The fix introduces cond_resched() calls within the affected loops to allow the scheduler to preempt during large allocations. Patches are available from the official kernel git repositories:

• Kernel Git Commit 13a52f6
• Kernel Git Commit 2565558
• Kernel Git Commit 4104b00
• Kernel Git Commit 975355f
• Kernel Git Commit 9ab20fe

Debian users should refer to Debian LTS Advisory 30 and Debian LTS Advisory 45 for distribution-specific patches.

Workarounds

• Restrict access to the RDMA verbs interface by removing read/write permissions from /dev/infiniband/uverbs* devices for non-privileged users
• Unload the hns_roce_hw_v2 kernel module if RDMA functionality is not required: modprobe -r hns_roce_hw_v2
• Implement application-level limits on memory region sizes for RDMA operations where possible
• Use cgroups or namespaces to isolate and limit resources available to untrusted workloads accessing RDMA hardware

# Restrict RDMA verbs interface access
chmod 600 /dev/infiniband/uverbs*

# Unload the vulnerable module if not needed
modprobe -r hns_roce_hw_v2

# Blacklist the module to prevent auto-loading
echo "blacklist hns_roce_hw_v2" >> /etc/modprobe.d/blacklist-hns.conf