CVE-2026-43120

What it actually does

This is a Linux kernel memory-management flaw in the Intel RDMA driver, irdma. During memory-region re-registration, the driver may release an RDMA user memory object and then leave a stale pointer in the memory-region structure. If the operation fails and user space subsequently deregisters the same memory region, the kernel can attempt to release the same object again, causing a double free. Because this occurs in kernel context, successful exploitation can lead to kernel memory corruption, denial of service through a crash, and potentially local privilege escalation or compromise of kernel memory integrity/confidentiality. Exploitation requires local access and the ability to exercise RDMA/irdma functionality; it is not a remote network-only vulnerability by itself.

Why it matters to the business

Systems using affected Linux kernels with Intel RDMA/irdma support may be exposed to local kernel compromise or crashes if untrusted or compromised users can access RDMA functionality. The primary operational risk is workload or host instability on RDMA-enabled servers, including compute, storage, virtualization, HPC, AI/ML, or high-performance networking platforms. The EPSS score is very low and there is no known KEV listing or reported ransomware use, so broad exploitation is not currently indicated; however, kernel memory-corruption issues should still be prioritized on multi-user or high-value RDMA-enabled systems because a local foothold could become full host compromise.

How an attack unfolds

An attacker first obtains local code execution on a Linux system where the affected irdma driver is present and RDMA user-space interfaces are accessible. They create or use an RDMA memory region and invoke the memory-region re-registration path with translation re-registration enabled. The attacker then causes a failure after the driver has allocated and later released a new user memory object. Because the driver does not clear the associated pointer after release, the memory-region state still appears valid to later cleanup code. The attacker then triggers normal deregistration of the memory region, causing the kernel to release the same memory object a second time. This can corrupt kernel heap state, usually resulting in a kernel crash, and in more advanced scenarios may be shaped into broader kernel memory corruption or local privilege escalation. No public exploit maturity is currently indicated in the provided data.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix for the irdma rereg_user_mr double-free condition. Because no exact fixed package versions were provided, use the fixed kernel versions published by the relevant Linux distribution, appliance vendor, cloud image provider, or kernel maintainer. Prioritize patching systems where the irdma module is loaded, Intel RDMA hardware is present, or untrusted local users/containers can access RDMA device nodes. If immediate patching is not possible, reduce exposure by disabling or unloading the irdma driver where RDMA is not required, restricting access to RDMA device files and RDMA-capable workloads, limiting local shell/container access to trusted users, and applying standard kernel hardening controls such as secure boot, lockdown where appropriate, and least-privilege device access policies. Reboot into the patched kernel after installation; merely installing kernel packages is not sufficient if the system continues running the vulnerable kernel.

How to confirm the fix worked

Confirm the running kernel, not only the installed kernel package, has been updated to a vendor release containing the fix. Validate exposure by checking whether Intel RDMA/irdma support is present or loaded, for example with lsmod, modinfo, lspci, rdma link, and checks for /dev/infiniband devices. Systems without the irdma module, without compatible hardware, or without RDMA user access have substantially reduced practical exposure. After remediation, reboot and verify the active kernel version matches the fixed vendor advisory. Where feasible, perform a controlled RDMA registration/re-registration regression test using trusted RDMA test tooling and confirm no kernel warnings, KASAN reports, double-free messages, or oops/panic events occur in kernel logs.

Typical attack path

1. Gain local execution on a Linux system with an affected kernel and Intel RDMA/irdma functionality available.
2. Confirm access to RDMA user-space interfaces and the ability to create/register RDMA memory regions.
3. Register an RDMA memory region through the irdma driver.
4. Invoke memory-region re-registration with the translation re-registration path enabled.
5. Force or induce an error condition after the new user memory object has been allocated and released by the driver.
6. Call the normal memory-region deregistration path from user space.
7. Trigger a second release of the same kernel memory object, causing kernel memory corruption, crash, or potential privilege escalation.

How to detect it

Look for signs of prior exploitation or attempted triggering in kernel and system logs, especially on hosts with Intel RDMA hardware or the irdma driver loaded. Relevant sources include journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dump records, kdump/vmcore artifacts, audit logs for RDMA device access, EDR process telemetry, and shell history where available. Search for kernel allocator corruption, double-free reports, KASAN/KFENCE findings, oops or panic events, and messages involving irdma, ib_umem_release, rereg_user_mr, dereg_mr, or RDMA memory registration. Correlate these events with local user activity, execution of RDMA utilities or unfamiliar binaries, access to /dev/infiniband devices, and sudden host reboots. Absence of these indicators does not prove non-exploitation because a successful kernel exploitation attempt may leave minimal logs, while failed attempts commonly produce crashes or memory-corruption diagnostics.

• irdma
• ib_umem_release
• rereg_user_mr
• dereg_mr
• rereg_mr_trans
• BUG: kernel NULL pointer dereference
• BUG: unable to handle page fault
• kernel BUG at
• Oops:
• Kernel panic - not syncing
• general protection fault
• double free
• Double free
• KASAN: double-free
• KASAN: use-after-free
• KASAN: slab-out-of-bounds
• KFENCE: use-after-free
• slab: double free detected
• free(): double free detected
• corrupted double-linked list
• list_del corruption
• refcount_t: underflow
• /dev/infiniband/uverbs
• /dev/infiniband/rdma_cm
• /sys/module/irdma
• irdma.ko

What your security team should do

• Identify Linux systems with RDMA hardware or the irdma kernel module loaded and prioritize them for assessment.
• Patch and reboot RDMA-enabled systems to vendor kernel versions containing the fix, with highest priority for multi-user, shared compute, virtualization, HPC, AI/ML, and storage nodes.
• If patching is delayed, disable or blacklist the irdma module on systems that do not require Intel RDMA functionality.
• Restrict access to /dev/infiniband and RDMA user-space capabilities to trusted service accounts and workloads only.
• Review recent kernel logs on RDMA-enabled systems for double-free, slab corruption, KASAN, oops, panic, or irdma-related failures.
• Monitor for suspicious local execution of RDMA test or custom binaries by untrusted users, especially followed by kernel instability.
• Track distribution-specific advisories because fixed versions vary by Linux vendor and kernel branch.
• Treat unexpected crashes on RDMA-enabled hosts as potentially security-relevant until kernel logs and crash dumps are reviewed.