CVE-2026-64582

What it actually does

This is a race-condition use-after-free in the Linux kernel RDMA Soft-RoCE driver, specifically in the rxe_mmap() path. The vulnerable code removes an rxe_mmap_info structure from the pending mmap list and drops the lock while its reference count can still be decremented to zero by a concurrent completion queue destruction path. If a second thread destroys the associated RDMA completion queue during the mmap operation, the kernel can free the backing vmalloc memory while remap_vmalloc_range() is still walking page table entries. The most likely outcome is a kernel crash due to a NULL or invalid page being passed into vm_insert_page(), causing denial of service. The description also indicates a narrow page-level use-after-free primitive may be possible if stale PTEs are mapped into user space before being cleared, but successful exploitation for controlled privilege escalation is expected to be difficult due to the very small race window.

Why it matters to the business

Systems using the Linux kernel RDMA rxe/Soft-RoCE functionality may be vulnerable to a local denial-of-service condition. A local user or compromised process with access to RDMA user-verbs devices could potentially crash the host kernel, interrupting workloads, virtual machines, containers, storage paths, or high-performance computing jobs running on that system. Although the EPSS score is currently low and there is no known KEV listing or ransomware association, kernel-level memory corruption issues should be treated seriously because exploitability can improve over time as researchers refine race techniques.

How an attack unfolds

An attacker first needs local execution on a Linux system where the RDMA rxe driver is available and where the attacker can interact with RDMA user-verbs interfaces. The attacker creates or uses an RDMA object such as a completion queue and initiates an mmap operation through the uverbs interface, causing the kernel to enter rxe_mmap() and begin remapping vmalloc-backed memory into the attacker-controlled process. In parallel, another thread repeatedly issues a destroy operation for the same or related completion queue, attempting to trigger the kref_put() path that frees the mmap metadata and backing vmalloc object. If the destroy operation wins the race while remap_vmalloc_range() is walking page table entries, the kernel may dereference freed or cleared page mappings. In the common case this causes an immediate kernel oops or panic. In a more advanced scenario, the attacker attempts to preserve a stale mapping to a freed page and then wait for that page to be reallocated, potentially creating a use-after-free condition that could be abused for further kernel memory corruption, although the source description notes this is statistically difficult.

How to fix it

Apply a Linux kernel update that includes the upstream RDMA/rxe fix for this use-after-free in rxe_mmap(). Because no exact fixed package versions were provided, use the relevant distribution kernel advisory, stable kernel changelog, or vendor errata to identify the corrected kernel build. Reboot into the fixed kernel after installation; simply installing the package is not sufficient if the vulnerable kernel remains running. If immediate patching is not possible, reduce exposure by disabling the rxe/Soft-RoCE driver where it is not required, unloading the rdma_rxe/rxe-related module if safe, preventing automatic module loading through modprobe blacklist policy, and restricting access to RDMA user-verbs device nodes to only trusted users and services. On systems that do not require RDMA, consider disabling the RDMA stack entirely.

How to confirm the fix worked

Confirm the running kernel, not just the installed package, contains the fix by checking uname -a, distribution package metadata, and the vendor security advisory or kernel changelog for the RDMA/rxe rxe_mmap use-after-free fix. Verify whether the rxe/Soft-RoCE module is loaded with lsmod or equivalent tooling, and confirm whether /dev/infiniband/uverbs* device nodes are present and accessible to unprivileged users. After remediation, validate that the host has been rebooted into the corrected kernel. Where safe and authorized, reproduce the previous crash condition in a non-production test system using a controlled regression test and confirm the kernel no longer emits call traces involving rxe_mmap(), remap_vmalloc_range(), vm_insert_page(), or validate_page_before_insert(). For mitigations, confirm that rdma_rxe cannot be loaded automatically and that unauthorized users cannot open RDMA uverbs devices.

Typical attack path

1. Gain local code execution on a Linux host where RDMA rxe/Soft-RoCE is enabled or loadable.
2. Confirm access to RDMA user-verbs device nodes such as /dev/infiniband/uverbs*.
3. Create RDMA resources, including a completion queue associated with rxe mmap metadata.
4. Start one thread that repeatedly invokes mmap on the RDMA uverbs file descriptor to enter rxe_mmap().
5. Start a second thread that repeatedly destroys the completion queue to trigger the freeing path while mmap is still in progress.
6. Win the race between remap_vmalloc_range() and the completion queue destruction path.
7. Cause a kernel crash, or in a more sophisticated attempt, obtain a stale user mapping to a freed vmalloc page for further exploitation.

How to detect it

To determine whether exploitation may already have occurred, review kernel logs, persistent journal entries, crash dumps, and console logs for oops or panic events involving the RDMA rxe driver and mmap paths. Relevant sources include dmesg output, /var/log/kern.log, /var/log/messages, systemd journal entries for the kernel facility, kdump/vmcore artifacts, and any centralized log collection receiving kernel messages. Look for general protection faults, NULL pointer dereferences, KASAN reports, or call traces that include validate_page_before_insert(), vm_insert_page(), remap_vmalloc_range_partial(), remap_vmalloc_range(), rxe_mmap(), ib_uverbs_mmap(), or rxe_mmap_release(). Correlate crash timing with local processes opening /dev/infiniband/uverbs* devices, repeated mmap activity, or RDMA completion queue creation and destruction. If auditd, eBPF, syscall tracing, or EDR telemetry is available, search for unusual local processes accessing RDMA uverbs device nodes, especially non-RDMA applications, user-compiled binaries, proof-of-concept names, or processes that rapidly perform mmap and ioctl operations against /dev/infiniband/uverbs*. Because exploitation is primarily a race that often results in a crash, absence of persistent files does not rule out attempted exploitation; kernel crash artifacts are the most useful evidence.

• validate_page_before_insert
• KASAN: null-ptr-deref
• Oops: general protection fault
• vm_insert_page
• remap_vmalloc_range_partial
• remap_vmalloc_range
• rxe_mmap
• rxe_mmap_release
• ib_uverbs_mmap
• DESTROY_CQ
• /dev/infiniband/uverbs
• rdma_rxe
• Soft-RoCE
• vmalloc_to_page() returns NULL
• vfree(ip->obj)
• kfree(ip)

What your security team should do

• Prioritize patching Linux systems that have RDMA, Soft-RoCE, InfiniBand, high-performance networking, storage fabrics, or user-accessible /dev/infiniband/uverbs* devices enabled.
• Inventory systems with the rdma_rxe or related rxe module loaded and identify which users or services can access RDMA user-verbs device nodes.
• Apply vendor-supported kernel updates and reboot affected hosts into the fixed kernel as soon as operationally feasible.
• If patching is delayed, disable or blacklist the rxe/Soft-RoCE module on systems that do not explicitly require it.
• Restrict /dev/infiniband/uverbs* permissions to trusted service accounts and remove unnecessary users from RDMA-related groups.
• Monitor kernel logs for general protection faults, KASAN reports, or call traces containing rxe_mmap, ib_uverbs_mmap, remap_vmalloc_range_partial, or validate_page_before_insert.
• Treat unexpected kernel crashes on RDMA-enabled systems as potentially security-relevant and preserve crash dumps, kernel logs, and process execution history for investigation.
• Track distribution advisories for exact fixed kernel package versions because the provided vulnerability metadata does not include per-package fixed versions.