CVE-2026-31492

What it actually does

CVE-2026-31492 is a local denial-of-service flaw in the Linux kernel Intel RDMA irdma driver. During irdma_create_qp, an error path can call irdma_destroy_qp after ib_copy_to_udata fails, but before the free_qp completion object has been initialized. Cleanup then waits on an uninitialized completion, which can cause a kernel hang, blocked task, crash, or other availability-impacting failure on systems using the affected RDMA driver. The issue requires local access and the ability to exercise RDMA userspace interfaces; it does not provide confidentiality or integrity impact based on the published description.

Why it matters to the business

Affected Linux systems with Intel RDMA hardware or the irdma driver exposed to local users may be vulnerable to a system-level availability event. A low-privileged local user or compromised local account could potentially crash or hang workloads that depend on the host, affecting compute, storage, database, virtualization, or HPC environments where RDMA-capable systems are used. The current EPSS is very low, there is no known KEV listing, and no public exploit maturity is reported, so this is primarily a targeted local stability risk rather than an internet-scale exploitation concern.

How an attack unfolds

An attacker first obtains local access to a Linux host where the affected irdma RDMA driver is present and usable. They then interact with the RDMA userspace verbs interface to trigger QP creation through irdma_create_qp. By causing the ib_copy_to_udata operation to fail at the vulnerable point, the kernel follows an error cleanup path that invokes irdma_destroy_qp. Because the free_qp completion has not yet been initialized, the cleanup path can wait on invalid or uninitialized synchronization state. The practical result is denial of service: the kernel may hang, emit blocked-task or call-trace diagnostics, or crash, disrupting services running on the host.

How to fix it

Update the Linux kernel to a vendor release that includes the upstream fix for the irdma_create_qp initialization order issue. Because no exact fixed package versions were provided, use the applicable distribution or appliance vendor advisory for the corrected kernel build. Where immediate patching is not possible, reduce exposure by unloading or disabling the irdma driver if RDMA is not required, restricting local user access to RDMA devices such as /dev/infiniband/uverbs*, limiting membership in groups that can access RDMA device nodes, and applying least-privilege controls to workloads running on RDMA-capable systems. Reboot into the corrected kernel after patching; simply installing kernel packages is not sufficient until the fixed kernel is active.

How to confirm the fix worked

Confirm the running kernel version is the vendor-fixed build, not only that the package is installed. Verify whether the irdma module is loaded with commands such as lsmod, modinfo, or equivalent endpoint inventory tooling. Check vendor changelogs or kernel source packages for the fix that initializes the free_qp completion before ib_copy_to_udata in irdma_create_qp. If RDMA is not required and mitigation was chosen, confirm the irdma module is not loaded and RDMA character devices are not accessible to untrusted users. After remediation, monitor kernel logs for absence of new irdma_create_qp, irdma_destroy_qp, wait_for_completion, blocked task, or kernel panic events during RDMA operations.

Typical attack path

1. Gain local shell, application-level code execution, or another form of local access on an affected Linux host.
2. Confirm that RDMA userspace interfaces and the Intel irdma driver are present, typically through /dev/infiniband/uverbs* and loaded kernel modules.
3. Invoke RDMA queue pair creation through userspace verbs in a way that reaches irdma_create_qp.
4. Cause the ib_copy_to_udata operation to fail during QP creation.
5. Trigger the vulnerable cleanup path, where irdma_destroy_qp waits on the uninitialized free_qp completion.
6. Induce a host hang, kernel crash, or blocked kernel task, causing denial of service.

How to detect it

To assess whether this was already exploited or triggered, review kernel logs from journald, dmesg, /var/log/kern.log, /var/log/messages, crash dumps, and centralized EDR/SIEM telemetry for events involving the irdma driver around system hangs, panics, reboots, or blocked tasks. Look for call traces that include irdma_create_qp, irdma_destroy_qp, ib_copy_to_udata, wait_for_completion, or RDMA userspace verbs activity. Correlate suspicious events with access to /dev/infiniband/uverbs* devices, process execution by non-administrative users, unexpected RDMA test tools, and audit records for RDMA character device opens. Because this is a local kernel denial-of-service condition, there may be no network IOC; the strongest evidence is temporal correlation between local RDMA device use and kernel instability or crash artifacts.

• irdma_create_qp
• irdma_destroy_qp
• ib_copy_to_udata
• free_qp
• wait_for_completion
• RDMA/irdma
• irdma
• /dev/infiniband/uverbs
• /dev/infiniband/uverbs0
• /dev/infiniband/rdma_cm
• INFO: task
• blocked for more than
• kernel panic
• BUG: kernel NULL pointer dereference
• Call Trace:
• Kernel panic - not syncing

What your security team should do

• Prioritize patching RDMA-capable Linux systems that load the irdma driver, especially shared compute, HPC, virtualization, storage, and multi-user systems.
• Inventory hosts with Intel RDMA hardware, loaded irdma modules, or /dev/infiniband/uverbs* devices exposed to local users.
• If patching is delayed, disable or unload the irdma driver where RDMA is not operationally required.
• Restrict access to RDMA userspace device nodes to trusted administrative or service accounts only.
• Review kernel, system, and audit logs for signs of prior local triggering, including irdma call traces, blocked tasks, kernel panics, and RDMA device access by unexpected users.
• Treat this as a local privilege-bound availability issue: focus on hardening local access paths and isolating untrusted workloads rather than perimeter network controls.
• Track distribution-specific advisories because fixed versions vary by kernel branch and vendor backport policy.