CVE-2026-46325

What it actually does

The flaw is in the Linux kernel RDMA RXE, or Soft-RoCE, memory-region address translation logic. When an RDMA memory region is registered with a page size that differs from the system PAGE_SIZE, the driver can calculate the wrong virtual address for a supplied I/O virtual address. This can cause RDMA operations to read from, write to, or reference an unintended kernel-mapped page offset. Depending on workload and memory layout, the result may be kernel memory corruption, unintended data exposure, data integrity loss, or a kernel panic/denial of service.

Why it matters to the business

Systems using Linux Soft-RoCE/RDMA may be at risk of crashes or memory corruption triggered over the network, potentially disrupting storage, clustering, virtualization, high-performance computing, or other RDMA-dependent services. The CVSS score is critical, but public exploitation is not currently indicated, EPSS is low, and it is not listed in CISA KEV, so organizations should prioritize remediation based on whether RXE/RDMA is enabled or exposed.

How an attack unfolds

An attacker first needs network reachability to a service or endpoint using the Linux RXE Soft-RoCE RDMA stack. They then cause or participate in RDMA memory registration and operations involving scatter-gather memory regions where the RDMA memory-region page size differs from the host system page size. By triggering RDMA access to carefully positioned I/O virtual addresses, the vulnerable kernel path can translate the address to the wrong backing virtual address. The incorrect translation can lead to reads or writes against unintended memory, causing data corruption, disclosure, or a kernel crash. Practical exploitation is likely dependent on RDMA service exposure, kernel configuration, memory-region registration behavior, and the ability to influence RDMA operations.

How to fix it

Upgrade to a Linux kernel version or vendor kernel package that includes the RDMA/rxe fix for memory-region page-size handling. Because no specific affected product or fixed-version list was provided, use the relevant Linux distribution, appliance, cloud image, or kernel vendor advisory to identify the first fixed kernel for this issue. If immediate patching is not possible, reduce exposure by disabling RXE/Soft-RoCE where it is not required, unloading or preventing loading of the rdma_rxe module, removing unused RXE interfaces, and restricting RDMA traffic to trusted management or storage networks. Do not rely on network filtering alone where untrusted workloads can invoke local RDMA functionality.

How to confirm the fix worked

Confirm that the running kernel package includes the upstream or vendor backport for the RDMA/rxe memory-region page-size conversion fix. Verify whether RXE is in use by checking loaded RDMA modules and RDMA links, for example through standard system tools such as lsmod, modinfo, rdma link, and distribution package inventory commands. After patching, reboot into the fixed kernel if required and confirm the old vulnerable kernel is not still running. Where safe and appropriate, validate RDMA functionality with existing regression or vendor-supported RDMA tests covering RXE, memory registration, and scatter-gather I/O on systems with differing page-size configurations.

Typical attack path

1. Identify a Linux system with RDMA RXE/Soft-RoCE enabled and reachable over the network.
2. Connect to or interact with an RDMA-capable service or protocol path that uses RXE-backed memory registration.
3. Trigger memory-region registration using scatter-gather layouts where the memory-region page size differs from the system PAGE_SIZE.
4. Issue RDMA read, write, send, or related operations against I/O virtual addresses that cross affected scatter-gather boundaries.
5. Cause the kernel RXE driver to resolve the I/O virtual address to an incorrect virtual address.
6. Leverage the resulting behavior to crash the kernel, corrupt data, or potentially access unintended memory.

How to detect it

Look for historical signs of kernel instability or RDMA RXE failures around systems using Soft-RoCE. Relevant sources include kernel logs, journald, syslog, crash dumps, kdump/vmcore artifacts, RDMA service logs, storage protocol logs, and network telemetry for RDMA/RoCE-capable interfaces. Search for kernel Oops, panic, page fault, general protection fault, or memory corruption messages with call traces involving RXE or RDMA memory-region functions. Also review unexpected restarts of hosts running RXE, sudden failures in RDMA-backed storage or clustering services, and unusual RDMA connection attempts from untrusted addresses. There are no unique public exploit indicators for this issue, so detection should focus on suspicious RDMA exposure combined with kernel crash artifacts referencing rdma_rxe, rxe_mr, or related RDMA memory registration paths.

• rdma_rxe
• rxe_mr
• rxe_set_page
• rxe_map_mr_sg
• rxe_mr_iova
• Soft-RoCE
• RXE
• BUG: unable to handle page fault
• Unable to handle kernel paging request
• general protection fault
• kernel BUG
• Oops:
• Kernel panic
• Call Trace:

What your security team should do

• Prioritize systems that have rdma_rxe or Soft-RoCE enabled, especially hosts exposing RDMA-backed storage, clustering, virtualization, or HPC services.
• Patch affected Linux kernels using vendor-supported updates and ensure systems reboot into the fixed kernel.
• Disable RXE/Soft-RoCE on systems that do not explicitly require it.
• Restrict RDMA-capable interfaces and ports to trusted networks and block exposure from untrusted segments.
• Review kernel panic, Oops, and RDMA-related logs for evidence of prior crashes or suspicious RDMA activity.
• Monitor vendor advisories for exact fixed kernel versions and any later exploitability updates, since the current exploit maturity is reported as none and EPSS is low.