CVE-2026-64582: RDMA/rxe: Fix a use-after-free problem in rxe_mmap

1. In CISA KEV: not seen
2. Exploited (reported): not seen
3. Scanning observed: not seen
4. Proof of concept public: not seen
5. Not establishedNothing in the sources we check

DescriptionNVD

In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix a use-after-free problem in rxe_mmap rxe_mmap() removes a rxe_mmap_info struct from the pending_mmaps list and releases pending_lock while the struct's kref is still at 1: list_del_init(&ip->pending_mmaps); spin_unlock_bh(&rxe->pending_lock); /* ref == 1, no lock held */ ret = remap_vmalloc_range(vma, ip->obj, 0); /* walks PTEs */ [...] rxe_vma_open(vma); /* kref_get, ref → 2 */ remap_vmalloc_range_partial() walks PTEs without any lock. A concurrent DESTROY_CQ ioctl on another CPU calls: kref_put(&q->ip->ref, rxe_mmap_release) /* ref 1→0 */ vfree(ip->obj) /* clears vmalloc PTEs mid-walk */ kfree(ip) /* frees rxe_mmap_info */ This yields: 1. Kernel crash, vmalloc_to_page() returns NULL when vfree wins the per-PTE race -> vm_insert_page(NULL) → GPF in validate_page_before_insert 2. Page UAF, vmalloc_to_page() reads a stale PTE before vfree clears it. User VMA holds a PTE to a free'd page which might eventually get reallocated later by vmalloc which allows the attacker to get a clean page-level UAF. It is worth noting that even though a page-level UAF is possible given the strong primitive, it is statistically very difficult to achieve given the very short time window (after the last insert_page and before the kref_get).

Exploitation

Unlikely (under 1%). EPSS under 1%, or no score yet.

CISA KEV

Not listed

Public check

No public nuclei template

Weakness

Use After Free · Memory Corruption

Vendor

Linux

Published

August 2026

Band

Unlikely (under 1%), August 2026

• NVD entrynvd.nist.gov
• Vendor advisorygit.kernel.org
• CVE recordcve.org