CVE-2021-47392

What it actually does

The flaw leaves per-device RDMA IDs on the listen_list with incorrect state after cma_listen_on_all() failure, preventing cma_cancel_listens() on destroy and leaking refcounts that deadlock _destroy_id().

Why it matters to the business

RDMA-enabled systems can experience kernel deadlocks or hangs during cleanup of failed listener setups, disrupting high-performance networking workloads and requiring reboots.

How an attack unfolds

An attacker with local or RDMA access triggers a failure in cma_listen_on_all(), then destroys the cmid via ucma_destroy_id; the wrong state skips listener cancellation, leaking references and blocking completion of the destroy path.

How to fix it

Update the Linux kernel to a version containing the atomic unwind fix under the lock in rdma_cma_listen_on_all(); rebuild and reboot affected hosts.

How to confirm the fix worked

Confirm the patch is present by inspecting rdma_cma.c for the lock-protected error unwind in cma_listen_on_all(); test by exercising listen failure followed by cmid destroy and verifying no deadlock occurs.

Typical attack path

1. Obtain access to a system using RDMA/CMA interfaces
2. Cause cma_listen_on_all() to fail for a cmid
3. Invoke ucma_destroy_id or equivalent close path
4. Trigger the refcount deadlock in _destroy_id

How to detect it

Inspect kernel logs and task traces for blocked processes in _destroy_id, wait_for_completion, or schedule_timeout within rdma_cm/rdma_ucm; look for repeated ucma_write or vfs_write entries from userspace RDMA applications leading to D-state hangs.

What your security team should do

• Prioritize kernel updates on all RDMA-enabled hosts
• Review and restrict unprivileged access to RDMA/CMA user-space interfaces
• Monitor for kernel task hangs in rdma_cm and rdma_ucm modules