CVE-2026-45852

What it actually does

This is a local Linux kernel memory-corruption flaw in the RDMA RXE software driver. During Shared Receive Queue creation, the kernel stores a queue pointer in the SRQ object before copying data back to user space. If that copy_to_user() operation fails, the queue is freed but the SRQ object still holds the stale pointer. Error cleanup later frees the same queue a second time, creating a double-free condition in kernel memory. A local authenticated user who can reach the RDMA verbs/RXE code path may be able to crash the kernel or potentially manipulate freed kernel memory to gain elevated privileges, depending on kernel configuration, allocator behavior, and exploit reliability.

Why it matters to the business

Successful exploitation can result in host instability, denial of service, or privilege escalation from a local user or compromised low-privilege process to kernel-level control. Systems using the Linux kernel with RDMA RXE enabled or available are most relevant. Although the current EPSS is low, there is no KEV listing, and no public exploit maturity is reported, the CVSS impact is high because kernel memory corruption can affect confidentiality, integrity, and availability on affected hosts.

How an attack unfolds

An attacker first needs local code execution or a valid local account on a Linux system where the vulnerable RDMA RXE path is present and reachable. The attacker interacts with the RDMA userspace interface to create a Shared Receive Queue. They intentionally cause the kernel's copy_to_user() operation to fail after the RXE queue pointer has already been assigned into the SRQ object. The kernel then frees the queue during immediate error handling but leaves the stale pointer behind. When the SRQ creation error unwinds, cleanup logic frees the same queue again. At minimum, this can trigger a kernel crash or oops; with additional heap-shaping and allocator manipulation, the double free may be used as a primitive for local privilege escalation.

How to fix it

Apply a Linux kernel update from the relevant distribution or vendor that includes the RDMA/rxe fix moving assignment of srq->rq.queue until after the copy_to_user() operation succeeds. No exact fixed package versions were provided, so use vendor advisories and kernel changelogs for the deployed distribution to identify the first non-vulnerable kernel. If immediate patching is not possible, reduce exposure by disabling or preventing loading of the rdma_rxe module where RXE is not required, restricting local user access to RDMA devices and verbs interfaces, and limiting untrusted local code execution. Consider blacklisting rdma_rxe on systems that do not need software RDMA over Ethernet.

How to confirm the fix worked

Confirm that systems are running a vendor kernel containing the RDMA/rxe double-free fix. Review package changelogs, kernel advisory notes, or source patches for the rxe_srq_from_init() change that assigns srq->rq.queue only after copy_to_user() succeeds. Validate runtime exposure by checking whether rdma_rxe is loaded or loadable and whether RDMA userspace devices are accessible to non-administrative users. On Linux systems, useful checks include reviewing the running kernel version with uname -r, installed kernel package versions through the distribution package manager, loaded modules with lsmod, and RDMA device visibility with rdma link or ibv_devices where available. A fixed or mitigated system should either run a patched kernel or not expose the vulnerable RXE code path to untrusted local users.

Typical attack path

1. Obtain local execution on an affected Linux system, such as through a shell, compromised service account, container escape prerequisite, or low-privileged user account.
2. Confirm that RDMA/RXE functionality is present and accessible, commonly through the rdma_rxe kernel module and RDMA userspace interfaces.
3. Invoke the RDMA verbs path that creates a Shared Receive Queue through ib_create_srq_user/rxe_create_srq.
4. Force the userspace copy operation to fail at the vulnerable point, leaving srq->rq.queue pointing to already-freed memory.
5. Trigger cleanup of the failed SRQ creation path, causing rxe_srq_cleanup() to free the same queue a second time.
6. Use the resulting kernel memory corruption to crash the system or attempt privilege escalation through controlled heap reuse.

How to detect it

Look for evidence of attempted or successful exploitation in kernel logs, crash dumps, audit logs, and endpoint telemetry. Primary sources include dmesg output, journald kernel messages, /var/log/kern.log, /var/log/messages, /var/log/syslog, kdump/vmcore artifacts, auditd events, and EDR process telemetry around RDMA userspace tools or custom binaries. Focus on kernel oops or panic traces that include rdma_rxe, rxe_srq_from_init, rxe_queue_cleanup, rxe_srq_cleanup, rxe_create_srq, ib_create_srq_user, or kmem_cache_free. Also review module load history for rdma_rxe and user activity around RDMA device access. Because this is a local kernel memory-corruption issue, network indicators are not expected unless the initial access vector is separately known. Absence of these traces does not prove non-exploitation, because a successful local privilege-escalation attempt may not leave a clean crash signature.

• rdma_rxe
• rxe_srq_from_init
• rxe_queue_cleanup
• rxe_srq_cleanup
• rxe_elem_release
• rxe_create_srq
• ib_create_srq_user
• kmem_cache_free
• BUG: kernel NULL pointer dereference
• BUG: unable to handle kernel paging request
• general protection fault
• kernel BUG at
• Oops:
• Call Trace:
• double free
• /sys/module/rdma_rxe
• /dev/infiniband/uverbs
• /dev/infiniband/rdma_cm

What your security team should do

• Prioritize patching Linux systems that expose RDMA/RXE functionality, multi-user shell access, shared compute workloads, or untrusted local code execution.
• Inventory systems with the rdma_rxe module loaded or available, and identify users or workloads with access to RDMA verbs interfaces.
• Where RXE is not business-required, disable or blacklist the rdma_rxe module as a compensating control until patched.
• Monitor for kernel oops, panic, or call traces involving rxe_queue_cleanup, rxe_srq_cleanup, rxe_create_srq, ib_create_srq_user, or kmem_cache_free.
• Treat suspicious crashes in the RDMA RXE path as potential exploitation attempts, especially if preceded by activity from low-privileged local users or untrusted workloads.
• Apply standard local privilege-escalation hardening: restrict interactive access, isolate untrusted workloads, enforce least privilege, and ensure kernel crash dumps and audit logs are retained for investigation.