CVE-2024-42285

What it actually does

Use-after-free in RDMA/iwcm where iw_conn_req_handler associates a conn_id with cm_id, but rdma_destroy_id frees both structures without ensuring cm_work_handler has completed all pending work, allowing access to freed rdma_id_private.

Why it matters to the business

Systems relying on RDMA networking face elevated crash and local privilege escalation risk; with 2,868 downstream dependents the flaw can propagate through kernels, containers, and appliances, disrupting high-performance compute and storage workloads until patched.

How an attack unfolds

An attacker with local access triggers rapid RDMA connection requests followed by immediate id destruction, racing the work handler to dereference the freed conn_id context and execute arbitrary code or cause denial of service.

How to fix it

Update the Linux kernel to a version containing commit d91d253c87fd1efece521ff2612078a35af673c6; rebuild and reboot affected hosts; where immediate patching is impossible, disable unused RDMA interfaces and restrict local user access to RDMA devices.

How to confirm the fix worked

Confirm the running kernel contains d91d253c87fd1efece521ff2612078a35af673c6 or later equivalent; exercise RDMA connection creation and teardown paths under load while monitoring for use-after-free warnings in dmesg; re-run any existing RDMA unit tests.

Typical attack path

1. Obtain local access on a system with RDMA/iWARP enabled
2. Issue crafted iw_cm connection requests that allocate conn_id structures
3. Trigger rdma_destroy_id on the associated cm_id while pending work items remain
4. Force cm_work_handler to execute after the structures are freed
5. Leverage the resulting dangling pointer for memory corruption or control-flow hijack

How to detect it

Search kernel logs for RDMA CM work-handler warnings, use-after-free stack traces referencing iw_conn_req_handler or cma_iw_handler, and unexpected process crashes involving rdma_id_private; correlate with process creation of RDMA-enabled applications around the same timestamp.

What your security team should do

• Prioritize kernel upgrades on all hosts exposing RDMA or iWARP
• Inventory systems with 2,868+ dependent packages and schedule phased rollouts before any external deadline
• Harden local access controls around RDMA device nodes until patches are deployed
• Add kernel crash and RDMA work-queue monitoring to existing detection pipelines