CVE-2026-92488

What it actually does

Failure of erdma_post_cmd_wait during erdma_destroy_qp, erdma_destroy_cq, erdma_dereg_mr or erdma_destroy_ah causes early return without releasing queue buffers, MTTs, doorbells, STAG/QPN/CQN/AHN identifiers; command-queue timeout permanently disables the queue, after which the RDMA core nulls pointers while the leaked objects remain allocated.

Why it matters to the business

Over time the kernel leaks limited RDMA resources, raising the chance of exhaustion, denial of service, or later memory-safety issues on systems that use the erdma driver; because the flaw is local-only and exploitation has not been observed, immediate operational risk remains low.

How an attack unfolds

An attacker with local access triggers repeated or timed failure of the hardware command queue during object teardown; the resulting leaks accumulate until resources are exhausted or a subsequent use-after-free path becomes reachable after the RDMA core discards its references.

How to fix it

Upgrade to a kernel that contains the fix for CVE-2026-92488; the corrected erdma code now releases all software-owned resources and returns success even when the hardware command fails.

How to confirm the fix worked

Confirm the running kernel contains the upstream commit that changes erdma_destroy_* routines to release resources on command failure; scan dmesg for the new warning emitted on teardown errors.

Typical attack path

1. Obtain local unprivileged access on a Linux host using the erdma RDMA driver
2. Create RDMA objects (QP, CQ, MR, AH) and force erdma_post_cmd_wait to fail or time out
3. Observe that destroy paths return early, leaving buffers and identifiers allocated
4. Repeat until resource exhaustion or a secondary memory-safety condition is reached

How to detect it

Search kernel logs for erdma command timeouts or the new warning added by the fix; inspect /proc or crash dumps for orphaned RDMA object counts after repeated create/destroy cycles.

What your security team should do

• Apply the corrected kernel as soon as it is available in your distribution
• Monitor EPSS and KEV status; current values indicate low urgency
• Limit use of the erdma driver to systems that truly require it