CVE-2026-46265: Linux RDMA/hns WQ_MEM_RECLAIM Workqueue Bug – High Availability Risk

Technical summary

The vulnerability stems from improper workqueue configuration in the hns_roce driver's QP (queue pair) destruction path. When RDMA/RPC operations trigger a reset, the hns_roce_irq_workq workqueue attempts to flush work from a WQ_MEM_RECLAIM context (xprtiod worker), but the hns_roce_irq_workq itself lacks the WQ_MEM_RECLAIM flag. This violates kernel workqueue ordering constraints designed to prevent deadlocks during memory reclamation. The issue manifests as a check_flush_dependency() warning in kernel/workqueue.c, indicating a potential deadlock hazard. The fix requires marking hns_roce_irq_workq with WQ_MEM_RECLAIM so that queue pair destruction—which involves memory freeing—can safely operate within memory-pressure contexts.

Business impact

Organizations relying on NFS or RPC-based services over RDMA using Huawei RoCE adapters face potential service interruptions. During memory pressure or cluster resets, kernel warnings can escalate to kernel panics or forced system restarts. This is most critical for high-performance computing clusters, distributed storage systems (e.g., Ceph), and enterprise data centers using RoCE for low-latency I/O. Unplanned downtime and data availability issues could result. The risk is moderate in scale because it requires specific hardware and workload conditions, but the consequences are severe when triggered.

Affected systems

Linux systems using the Huawei RoCE (RDMA/hns) driver are affected. Vulnerable versions are those prior to the patch inclusion. The vulnerability is present in systems running sunrpc over RDMA, particularly on Arm64-based servers with Huawei RoCE NICs. Check your kernel version and confirm hns_roce module presence with 'lsmod | grep hns_roce'. Desktop and non-RDMA Linux systems are not affected.

Exploitability

This is not a remotely exploitable vulnerability in the traditional sense. It cannot be triggered by external network traffic. Instead, it is a latent kernel stability bug triggered internally by specific workload patterns: RDMA connection resets under high memory pressure or during sunrpc failover events. An attacker with local ability to trigger RDMA reset conditions (e.g., via deliberately degraded network conditions on local RoCE fabric) could potentially amplify the denial-of-service impact. The CVSS score of 7.5 (HIGH) reflects the availability impact (A:H) with low attack complexity, though exploitation requires local presence or control of RoCE fabric topology.

Remediation

Apply the upstream Linux kernel patch that adds the WQ_MEM_RECLAIM flag to the hns_roce_irq_workq workqueue allocation. Verify patch inclusion in your kernel version before deploying. For systems unable to patch immediately, operational mitigations include: (1) avoiding aggressive RDMA connection resets during memory pressure by tuning RPC timeout values, and (2) monitoring kernel logs for WQ_MEM_RECLAIM warnings as an early warning sign. Reboot systems exhibiting this warning to clear transient state.

Patch guidance

Check your Linux kernel version for inclusion of the RDMA/hns WQ_MEM_RECLAIM fix. The patch was merged into the kernel's rdma/hns driver code path. Verify against the official Linux kernel commit history and your distribution's kernel advisory. Most recent stable kernels (5.15+) should include this fix; check your kernel changelog. When patching, ensure your hns_roce driver module is recompiled or your kernel is fully rebuilt. Test in a staging environment by reproducing RPC over RDMA workloads with network resets to confirm the warning no longer appears in dmesg.

Detection guidance

Monitor kernel logs (dmesg, journalctl) for the specific warning: 'WQ_MEM_RECLAIM xprtiod:xprt_rdma_connect_worker is flushing !WQ_MEM_RECLAIM hns_roce_irq_workq'. Grep logs with: 'journalctl -xe | grep -i "WQ_MEM_RECLAIM"' or 'dmesg | grep check_flush_dependency'. Monitor for unexpected kernel panics or resets coinciding with RDMA workload spikes or RPC failover events. If hns_roce is loaded ('lsmod | grep hns_roce'), enable workqueue debugging in sysfs to catch early warnings: 'echo 1 > /sys/module/workqueue/parameters/debug_force_rcu_schedule'.

Why prioritize this

Prioritize this patch for systems running NFS over RDMA or any sunrpc-based services on RoCE hardware. The CVSS score of 7.5 reflects high availability impact with low complexity, but real-world impact is limited to specific hardware/workload combinations. Patch within 60 days for production clusters using RoCE; expedite to 30 days if you have observed the WQ_MEM_RECLAIM warning in your logs. Desktop systems and non-RDMA deployments can defer this patch.

Risk score, explained

The CVSS 7.5 (HIGH) score is driven by CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. The 'A:H' (availability high) reflects kernel panic potential; however, the 'AV:N' (network vector) is somewhat generous here—true exploitation requires local RoCE fabric control or triggering reset conditions from within the system. The lack of confidentiality or integrity impact keeps it from CRITICAL. The score accurately captures the severity for affected deployments but overstates risk for organizations not using RoCE.

Frequently asked questions