CVE-2024-56722

What it actually does

During RDMA/hns reset, failure to destroy resources like QP/CQ/MR triggers repeated non-rate-limited printk calls; when many resources are involved the flood of logging can starve the CPU and cause a soft lockup or stuck condition.

Why it matters to the business

Systems using the hns RDMA driver may become unresponsive during hardware resets or driver reloads, interrupting storage, networking, or high-performance computing workloads that rely on the adapter.

How an attack unfolds

An attacker with local access or the ability to induce repeated device resets (for example by unloading the driver or triggering hardware faults) can cause a large number of resource-destroy commands to fail, flooding the kernel log and locking up a CPU core.

How to fix it

Upgrade the Linux kernel to a version containing commit 31c6fe9b79ed42440094f2367897aea0c0ce96ec (or later stable backports) which removes unnecessary print statements and converts remaining messages to ratelimited variants.

How to confirm the fix worked

Verify the running kernel contains commit 31c6fe9b79ed42440094f2367897aea0c0ce96ec or is newer than the vulnerable commit; confirm absence of the original non-rate-limited printk calls in the hns reset paths via source inspection or kernel binary diff.

Typical attack path

1. Obtain local access or ability to trigger RDMA device reset
2. Cause repeated failures of QP/CQ/MR destroy commands
3. Generate high volume of non-rate-limited error messages
4. CPU becomes stuck processing printk output

How to detect it

Search kernel logs and dmesg for repeated hns error messages without rate limiting during reset events; look for soft-lockup or hung-task stack traces referencing the RDMA destroy paths.

What your security team should do

• Prioritize kernel upgrade on all systems exposing the hns RDMA driver
• Apply the fix in development and staging environments first to validate stability
• Monitor kernel logs for soft-lockup or hung-task warnings during driver resets until patched
• Limit local user access to RDMA interfaces where possible until remediation is complete