On April 8, 2025, Microsoft published a security advisory for CVE-2025-22010, a vulnerability in the Linux kernel’s RDMA driver that can cause the operating system to hang. The flaw, rated 5.5 on the CVSS scale, allows a local user to trigger a soft lockup by requesting an extremely large memory region through the hns_roce driver. Microsoft confirmed that Azure Linux is affected and has shipped a fix in its latest kernel updates.

A Loop Without a Yield: Why the Kernel Freezes

The hns_roce_hw_v2 driver, which supports Huawei’s RDMA hardware, contains a function that allocates page-table entries when a user registers a memory region (MR). For typical MR sizes—a few gigabytes or less—the allocation loop finishes in milliseconds. But when the MR is massive, on the order of hundreds of gigabytes, the loop iterates millions of times without voluntarily yielding the CPU. The kernel’s watchdog timer then declares a soft lockup, a state where a CPU core is stuck in kernel mode for too long (usually 20 seconds). The system doesn’t necessarily crash immediately, but it becomes unresponsive, services time out, and a hypervisor may reboot the virtual machine.

The kernel logs a telltale trace when this happens:

watchdog: BUG: soft lockup – CPU#27 stuck for 22s! [process]
[<ffffffff...>] hns_roce_mtr_create+0x...
[<ffffffff...>] alloc_mr_pbl+0x...
[<ffffffff...>] hns_roce_reg_user_mr+0x...

According to the National Vulnerability Database entry, the root cause is a missing preemption point. In kernel development terms, the loop does not call cond_resched(), a function that checks whether the scheduler needs to run and, if so, yields the CPU. Without it, the kernel can’t handle time-sensitive tasks—like network interrupts, watchdog pings, or even the scheduler itself—for the entire duration of the loop.

This isn’t a remote code execution hole. It requires local access and the ability to invoke RDMA verbs. But for multi-tenant clouds or shared clusters, an untrusted container or a compromised guest could easily weaponize the bug to knock a node offline.

The Fix: One Word That Changes Everything

Upstream Linux developers addressed the issue by inserting cond_resched() calls at strategic points inside the allocation loop. This one-function addition lets the scheduler preempt the task periodically, preventing the CPU starvation. The change is intentional to be lightweight for normal MR sizes—the yield only kicks in after a threshold that corresponds to very large registrations. This means that the overwhelming majority of workloads will see no performance impact.

The fix landed in the Linux mainline kernel and was backported to multiple stable trees, including version 6.12.21. Distributions like Ubuntu, Debian, Oracle Linux, and Amazon Linux quickly picked up the patch. Microsoft confirmed that Azure Linux incorporates the fix in its latest kernel packages and urged users to update immediately.

Who’s at Risk: Azure Linux, HPC Clusters, and Beyond

If you’re a Windows user, this CVE doesn’t touch your desktop. But if you manage any Linux virtual machines—especially those running in Azure or another cloud—you need to act. The hns_roce driver is common in high-performance computing, AI training clusters, and distributed databases that use RDMA for fast data movement.

Microsoft’s advisory states that Azure Linux is the only Microsoft product that includes the vulnerable library, but the company is monitoring for any additional impact. For IT pros, the risk vector is clear: any system where an unprivileged user can issue a huge memory region registration could be taken down. That includes shared cloud VMs, Kubernetes pods with RDMA device access, and even bare-metal HPC nodes.

A CVSS v3.1 base score of 5.5 (Medium) reflects the local access vector, the high availability impact, and the fact that no special privileges are required once RDMA verbs are accessible. In practice, however, many environments grant RDMA to all containers in a pod, making the attack surface wider than the score suggests.

What You Should Do Right Now

1. Patch Your Kernel

  • For Azure Linux, run your standard package manager update command (e.g., yum update or apt update). Microsoft has rolled the fix into the latest kernel packages.
  • For other distributions, check your vendor’s security advisory page. Ubuntu, Debian, and Oracle Linux, among others, have backported the patch to their supported kernels.

2. Check for the hns_roce Driver

Run lsmod | grep hns_roce on every node. If the driver is loaded, the system is potentially vulnerable. If you don’t actually need RDMA on that hardware, consider blocklisting the driver or removing the module until you’ve patched.

3. Restrict RDMA Access Short-Term

If an immediate kernel update isn’t feasible, tighten access to RDMA devices:
- Use udev rules to limit /dev/infiniband/* permissions to trusted users.
- In container environments, drop the IPC_LOCK capability and remove RDMA device nodes from the container’s filesystem view.
- If your stack supports memory region size limits (e.g., via rdma-core resource limits), enforce a conservative ceiling for untrusted tenants.

4. Monitor for Soft Lockup Symptoms

Set up alerting for kernel logs containing the phrase “soft lockup”. Tools like journalctl -k | grep -i "soft lockup" can catch post-event traces, but a real-time log monitor (Splunk, Elastic, etc.) is better. Any trace that includes hns_roce_mtr_create or alloc_mr_pbl confirms you’ve hit the bug.

5. Test After Patching

Even though the fix is minimal, any change in a performance-critical path demands validation. Run representative RDMA workloads in a staging environment. Pay attention to throughput and latency, especially for applications that register mid-sized MRs frequently. In tests by the upstream community, normal workloads saw no measurable regression.

6. Verify the Fix (for Custom Kernels)

If you build your own Linux kernels, ensure that the upstream commit adding cond_resched() to the hns_roce driver is included. You can inspect the source file drivers/infiniband/hw/hns/hns_roce_mr.c and search for cond_resched in the allocation loops. The patch is small and self-contained, so backporting it to older kernels is straightforward if distribution patches aren’t available.

How We Got Here: Transparency in Open-Source Security

This vulnerability is not new to the Linux community—it was quietly fixed upstream months ago and trickled into stable kernels. What makes it notable is Microsoft’s proactive disclosure. In October 2025, Microsoft began publishing CSFA/VEX advisories for open-source components used in its products, extending the same transparency it offers for Windows vulnerabilities. CVE-2025-22010 is one of the first tangible results of that program.

“One of the main benefits to our customers who choose to use the Azure Linux distro is the commitment to keep it up to date with the most recent and most secure versions of the open source libraries,” Microsoft stated in the advisory. “If impact to additional products is identified, we will update the CVE to reflect this.”

For security-conscious teams, this is a welcome shift. It means that Linux kernel flaws that affect Azure services are no longer buried in kernel changelogs—they come with proper CVEs, scores, and actionable guidance.

The Bigger Picture: Availability Bugs in a High-Speed World

RDMA is no longer a niche technology. It’s the backbone of modern AI training, high-frequency trading, and clustered databases. As adoption grows, so does the attack surface for availability threats. CVE-2025-22010 is a reminder that even a single missing yield in a kernel driver can cascade into an outage.

The fix, while simple, doesn’t address the deeper issue: many RDMA drivers were built for performance, not multi-tenant safety. Ongoing research into RDMA resource exhaustion shows that noisy-neighbor attacks can still cause disruption even without lockups. For cloud operators, this means that patching is only one piece of the puzzle—robust resource isolation and monitoring are just as critical.

Microsoft’s advisory gives Azure Linux users a clear signal to update. The broader lesson is that all RDMA-equipped systems, regardless of the cloud provider, need regular kernel hygiene. In the age of ever-faster interconnects, a soft lockup can have hard consequences.