CVE-2026-46265

What it actually does

This flaw affects the Linux kernel HNS RoCE RDMA driver workqueue behavior during Queue Pair destruction, particularly when RPC-over-RDMA/SUNRPC activity is present and a reset or disconnect path is triggered. The vulnerable path can flush work from a workqueue that is not marked WQ_MEM_RECLAIM while memory-reclaim-sensitive work is executing, producing a kernel workqueue dependency warning. On systems configured to panic on kernel warnings, or under repeated reset/error conditions, this can cause a local kernel panic or service disruption. The primary impact is availability loss; there is no indication from the provided details of confidentiality or integrity compromise.

Why it matters to the business

Organizations using Linux systems with HNS RoCE RDMA hardware and RPC-over-RDMA workloads, such as RDMA-backed storage or NFS/RDMA environments, may experience unexpected service outages, kernel warnings, degraded storage/network reliability, or full host crashes if kernel warnings are configured to panic. Although this issue is not currently in CISA KEV, has low EPSS, and has no reported exploit maturity, affected infrastructure can still face operational disruption because RDMA failures often impact storage, virtualization, HPC, or high-throughput backend services.

How an attack unfolds

An attacker or fault condition needs to reach a system using the affected Linux kernel RDMA/hns driver path, typically where HNS RoCE hardware is active and SUNRPC/RPC-over-RDMA is in use. The triggering condition occurs during RDMA connection teardown, reset, or Queue Pair destruction. By causing or inducing repeated RDMA connection failures, disconnects, or reset paths, the vulnerable code can flush the hns_roce IRQ workqueue from a memory-reclaim-sensitive workqueue context. This produces a kernel workqueue warning involving WQ_MEM_RECLAIM dependency checks. If the host is configured with panic_on_warn, the warning may escalate to a kernel panic, resulting in denial of service. Even without panic-on-warn, repeated triggering may cause noisy kernel logs, RDMA transport instability, failed reconnects, or service degradation.

How to fix it

Apply a Linux kernel update that includes the RDMA/hns fix marking the relevant HNS RoCE workqueue with WQ_MEM_RECLAIM. Because no exact fixed versions were provided, use the latest stable kernel or the latest security/bug-fix kernel supplied by the applicable Linux distribution or appliance vendor. Prioritize systems with HNS RoCE RDMA adapters, loaded hns_roce modules, and RPC-over-RDMA/SUNRPC workloads. If immediate patching is not possible, reduce exposure by disabling unused RDMA services, disabling RPC-over-RDMA where feasible, restricting network access to RDMA-capable services, avoiding unnecessary RDMA reset/reconnect churn, and reviewing whether kernel.panic_on_warn is enabled on production hosts. Treat disabling panic_on_warn as a risk-based mitigation only; it may reduce crash likelihood but does not correct the underlying driver bug.

How to confirm the fix worked

Confirm remediation by verifying the running kernel package includes the vendor patch for the RDMA/hns WQ_MEM_RECLAIM fix and that the system has rebooted into the updated kernel. Check loaded modules with commands such as lsmod for hns_roce, hns_roce_hw_v2, rpcrdma, and xprtrdma to determine exposure. Review kernel logs before and after patching for the absence of workqueue warnings containing WQ_MEM_RECLAIM, xprtiod, hns_roce_irq_workq, or hns_roce_v2_destroy_qp during RDMA reset or reconnect testing. Where safe, perform controlled RDMA reconnect, NFS/RDMA failover, or adapter reset validation in a test or maintenance window and confirm no WARNING trace is emitted.

Typical attack path

1. Identify a Linux host using HNS RoCE RDMA hardware and an affected kernel version.
2. Confirm that RDMA-backed SUNRPC/RPC-over-RDMA services are reachable or in use, such as NFS over RDMA.
3. Trigger RDMA disconnect, reconnect, or reset behavior through connection disruption, malformed traffic patterns, service restarts, or repeated session failures.
4. Cause the vulnerable Queue Pair destruction path to execute in the hns_roce driver.
5. Trigger the kernel workqueue dependency warning involving WQ_MEM_RECLAIM and hns_roce_irq_workq.
6. If the system is configured to panic on warnings, cause a kernel panic and availability outage; otherwise, cause RDMA service instability or repeated kernel warnings.

How to detect it

To determine whether this issue has already been triggered, review kernel logs, system journals, crash dumps, and monitoring alerts for workqueue dependency warnings involving WQ_MEM_RECLAIM, xprtiod, rpcrdma, and hns_roce. Useful sources include /var/log/kern.log, /var/log/messages, /var/log/syslog, journalctl -k output, dmesg captures, kdump/vmcore metadata, and RDMA/NFS service logs. Look for WARNING traces at kernel/workqueue.c check_flush_dependency followed by functions such as flush_work, hns_roce_v2_destroy_qp, ib_destroy_qp_user, rdma_destroy_qp, rpcrdma_ep_destroy, rpcrdma_xprt_disconnect, and xprt_rdma_connect_worker. Correlate these events with RDMA adapter resets, NFS/RDMA disconnects, host reboots, kernel panics, or service availability incidents. There are no known attacker-specific indicators in the provided data; detection should focus on kernel artifacts and repeated triggering patterns rather than attribution.

• workqueue: WQ_MEM_RECLAIM xprtiod:xprt_rdma_connect_worker
• is flushing !WQ_MEM_RECLAIM hns_roce_irq_workq:flush_work_handle
• WARNING: CPU:
• kernel/workqueue.c:2644 check_flush_dependency
• check_flush_dependency+0xe0/0x144
• start_flush_work.constprop.0
• __flush_work.isra.0
• flush_work+0x14/0x30
• hns_roce_v2_destroy_qp
• ib_destroy_qp_user
• rdma_destroy_qp
• rpcrdma_ep_destroy
• rpcrdma_ep_put
• rpcrdma_xprt_disconnect
• xprt_rdma_connect_worker
• process_one_work
• worker_thread
• hns_roce_hw_v2
• rpcrdma
• xprtiod
• hns_roce_irq_workq

What your security team should do

• Inventory Linux systems using HNS RoCE RDMA hardware and RPC-over-RDMA/SUNRPC workloads; prioritize those for patching.
• Apply the latest vendor-supported kernel containing the RDMA/hns WQ_MEM_RECLAIM fix and reboot into the updated kernel.
• Search historical kernel logs for the WQ_MEM_RECLAIM and hns_roce_irq_workq warning trace to identify prior triggering or instability.
• Review kernel.panic_on_warn settings on affected production systems to understand whether this warning could become a full host crash.
• Restrict access to RDMA and RPC-over-RDMA services to trusted networks and peers only.
• If patching is delayed, temporarily disable unused RDMA transports or RPC-over-RDMA functionality where operationally feasible.
• Monitor for repeated RDMA disconnects, adapter resets, Queue Pair destruction errors, and NFS/RDMA reconnect loops.
• Because this issue is not currently KEV-listed and EPSS is low, handle as a targeted infrastructure stability risk rather than an internet-wide emergency, unless RDMA-backed critical workloads are present.