CVE-2024-47735

What it actually does

Improper use of spin_lock_irq/spin_unlock_irq instead of the irqsave/irqrestore variants in RDMA/hns QP list handling can trigger raw_local_irq_restore warnings and potential lock state corruption under concurrent access.

Why it matters to the business

Systems using Huawei RoCE hardware may experience intermittent kernel warnings, reduced stability during RDMA connection setup, and in worst cases availability impact on high-performance networking workloads.

How an attack unfolds

A local attacker with access to RDMA interfaces triggers QP creation paths in the hns_roce driver while interrupts are manipulated, causing the mismatched spin unlock to fire the irqflag debug warning and potentially destabilize the kernel.

How to fix it

Update the Linux kernel to a version containing commit 07f0f643d7e570dbe8ef6f5c3367a43e3086a335 or later; for Rocky Linux 8 apply the listed mecab and mecab-ipadic module updates if applicable to the distribution kernel packaging.

How to confirm the fix worked

Confirm the presence of the fix commit in the running kernel source, verify absence of the warn_bogus_irq_restore stack trace during ib_register_device and hns_roce_create_qp calls, and test RDMA QP creation under load.

Typical attack path

1. Obtain local access on a system with hns_roce hardware and RDMA enabled
2. Invoke ib_create_qp or equivalent MAD QP creation routines under concurrent load
3. Trigger the add_qp_to_list path that holds spin_lock_irqsave but later calls spin_unlock_irq
4. Observe kernel warning or subsequent instability during device registration

How to detect it

Search kernel logs and dmesg for 'warn_bogus_irq_restore' combined with 'add_qp_to_list' and 'hns_roce_create_qp' stack frames; review audit logs for unusual local RDMA QP creation activity around device initialization.

• warn_bogus_irq_restore+0x30/0x40
• _raw_spin_unlock_irqrestore+0x84/0xc8
• add_qp_to_list+0x11c/0x148 [hns_roce_hw_v2]
• hns_roce_create_qp_common.constprop.0+0x240/0x780 [hns_roce_hw_v2]

What your security team should do

• Prioritize kernel updates on systems exposing RDMA/hns devices within the next patching cycle
• Monitor kernel logs for irqflag-debug warnings related to hns_roce_hw_v2
• Restrict unprivileged local RDMA access until patches are applied