Linux RDMA/hns: workqueue without WQ_MEM_RECLAIM risks a hang on QP teardown under memory reclaim

CVSS 7.5CVE-2026-46265Firmware, BMC & network fabriccurated

Impact

hns_roce_v2_destroy_qp() flushes hns_roce_irq_workq, which lacks WQ_MEM_RECLAIM, from the memory-reclaim context of the NFS/RDMA connect worker. The kernel warns about the flush dependency, and the real exposure is a stall: QP destruction frees memory, so flushing a non-reclaim workqueue from a reclaim worker can wedge the RDMA teardown path when the system is already under memory pressure, typically during an adapter reset. On a node whose storage is NFS over RDMA on HiSilicon/Huawei RoCE NICs, that means jobs stop on a hung mount and the node needs a reboot to clear - availability only, with no confidentiality or integrity impact in the record. Only fleets running hns_roce NICs are affected; Mellanox/Broadcom RDMA stacks are untouched by this fix.

Who can reach it

No attacker interaction is described: the path is triggered by an adapter reset while NFS/RDMA is in use, so it is a local availability bug reachable by whatever induces memory pressure or a device reset. The record's AV:N vector is the kernel CNA's generic rating and overstates reachability.

What to do

Move to the fixed stable kernel (the fix just adds WQ_MEM_RECLAIM to the hns_roce workqueue; five stable commits are in the record) and reboot each node with HiSilicon RoCE adapters. No vendor mitigation is published; until patched, avoiding NFS-over-RDMA on hns adapters removes the reported trigger.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-46265 https://git.kernel.org/stable/c/0cbec8b49270f3f0600b8e3ef5e8f0d233dcea27 https://git.kernel.org/stable/c/12761bd0ae16a80f237c2a65ab1b1064076cc74a https://git.kernel.org/stable/c/31b22ca4f5ab8c495fd8bb44c06573f1fb7833a2

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.