CVE-2024-47735 is a vulnerability identified in the Linux kernel specifically within the RDMA (Remote Direct Memory Access) subsystem, more precisely in the hns_roce_hw_v2 driver module. The issue stems from improper use of spinlock APIs related to interrupt handling: spin_unlock_irqrestore() was called while IRQs (interrupt requests) were still enabled, which violates kernel locking semantics. The root cause is misuse of spin_lock_irq()/spin_unlock_irq() functions when spin_lock_irqsave()/spin_unlock_irqrestore() should have been used instead. This incorrect locking behavior was detected through kernel lock debugging mechanisms, which generated warnings such as "raw_local_irq_restore() called with IRQs enabled". The call trace shows the problem occurring during queue pair (QP) creation and device registration routines within the hns_roce driver, which handles RDMA hardware from Huawei (HiSilicon). Improper interrupt flag restoration can lead to race conditions, deadlocks, or kernel instability. While no known exploits are currently reported in the wild, this vulnerability affects Linux kernel versions containing the faulty code identified by the commit hash 9a4435375cd151e07c0c38fa601b00115986091b. The vulnerability was publicly disclosed on October 21, 2024, and a patch has been applied in the kernel source to correct the locking calls and prevent IRQ mismanagement. No CVSS score has been assigned yet, but the technical details indicate a kernel-level concurrency bug in a critical subsystem used for high-performance networking and storage operations.

For European organizations, the impact of CVE-2024-47735 could be significant in environments relying on Linux servers with RDMA capabilities, particularly those using Huawei HiSilicon RDMA hardware or similar RDMA implementations. RDMA is commonly used in data centers, high-performance computing clusters, and enterprise storage networks to achieve low-latency and high-throughput communication. A kernel locking bug that mishandles interrupt flags can cause system instability, kernel panics, or deadlocks, potentially leading to denial of service (DoS) conditions. This can disrupt critical services, especially in sectors such as finance, telecommunications, research institutions, and cloud service providers that depend on stable and performant Linux infrastructure. Although no direct exploitation is known, the vulnerability could be leveraged by local attackers or malicious insiders with kernel-level access to cause system crashes or to escalate privileges by exploiting race conditions. The confidentiality and integrity impact is limited unless combined with other vulnerabilities, but availability impact is moderate to high due to potential system instability. European organizations with RDMA-enabled Linux systems should prioritize patching to maintain operational continuity.

1. Immediate application of the official Linux kernel patch that corrects the misuse of spin_lock_irq()/spin_unlock_irq() calls in the hns_roce_hw_v2 driver is essential. Monitor Linux kernel mailing lists and vendor advisories for updated stable kernel releases containing this fix. 2. For organizations using custom or long-term support kernels, backport the patch carefully to avoid regressions. 3. Conduct thorough testing in staging environments to verify that the patch resolves the IRQ handling issue without introducing new stability problems. 4. Restrict kernel module loading and ensure only trusted drivers are installed to reduce risk exposure. 5. Monitor kernel logs for warnings related to IRQ flag restoration or spinlock misuse, which could indicate attempts to trigger this vulnerability or related kernel bugs. 6. Implement strict access controls to limit local user privileges, as exploitation requires kernel-level code execution or local access. 7. Maintain up-to-date backups and disaster recovery plans to mitigate potential downtime caused by kernel instability. 8. Engage with hardware vendors to confirm compatibility and support for patched kernel versions, especially for RDMA hardware from Huawei or other suppliers using the hns_roce driver.