CVE-2026-53133

What it actually does

This flaw is in the Linux kernel RDMA user-memory mapping path. When an IOMMU is in use, RDMA memory registration can linearize a very large mapping into blocks split across multiple scatter-gather entries. For blocks at or above 4 GB, the RDMA block iterator used 32-bit stack values while reconstructing those entries, causing integer truncation and incorrect DMA address calculation. The result can be DMA to the wrong physical address range, leading to kernel memory corruption, data corruption, device faults, or kernel crashes. Depending on hardware, driver behavior, and access controls around RDMA devices, the practical impact is most likely local denial of service or corruption, with potential for more serious privilege-boundary impact if an untrusted user or container can access RDMA device nodes.

Why it matters to the business

Organizations running Linux systems with RDMA-capable hardware, such as HPC clusters, storage nodes, database platforms, virtualization hosts, or low-latency networking environments, could experience system instability, workload crashes, or data corruption if the vulnerable code path is triggered. The currently reported exploitation likelihood is low, with low EPSS, no known public exploit maturity, and no CISA KEV listing, but kernel memory-corruption issues should still be prioritized on systems where untrusted users, containers, or workloads have access to RDMA devices. Environments without RDMA hardware or without user-accessible RDMA interfaces have substantially lower practical exposure.

How an attack unfolds

An attacker would first need code execution in a context that can interact with RDMA user-space interfaces, typically through ibverbs or direct access to /dev/infiniband device nodes. They would then create or register a large user memory region that causes the IOMMU-backed RDMA mapping path to produce a block of at least 4 GB split across multiple scatter-gather entries. When the kernel RDMA umem iterator reconstructs those entries, the vulnerable implementation truncates address-related values to 32 bits and computes incorrect DMA addresses. Subsequent RDMA operations may cause the device to read from or write to unintended memory, resulting in kernel faults, IOMMU faults, data corruption, or a crash. There is no evidence from the provided intelligence that this vulnerability is being exploited in the wild or used by ransomware campaigns.

How to fix it

Apply a Linux kernel update from the relevant distribution or appliance vendor that includes the RDMA/umem fix for truncation when handling block sizes at or above 4 GB. If exact fixed package versions are not yet available in asset tooling, track vendor advisories and kernel changelogs for this CVE or the patch titled "RDMA/umem: Fix truncation for block sizes >= 4G." Where immediate patching is not possible, reduce exposure by disabling unused RDMA services and kernel modules, removing or restricting access to /dev/infiniband device nodes, preventing untrusted containers from receiving RDMA devices, enforcing least-privilege device cgroup and udev rules, and limiting shell or workload access on RDMA-enabled systems. Do not weaken IOMMU protections as a primary mitigation; instead, patch the kernel and restrict RDMA access.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel version is at or above the vendor-fixed release and that the vendor kernel changelog or advisory includes the RDMA/umem truncation fix. Validate that the system has rebooted into the patched kernel, not merely installed it, by comparing the installed package version with uname -r. Assess exposure by checking for RDMA hardware and interfaces using tools such as lspci, rdma link, ibv_devices, lsmod for RDMA-related modules, and the presence of /dev/infiniband/uverbs* device nodes. Review container runtime and device-cgroup policies to confirm untrusted workloads cannot access RDMA devices. In non-production environments, RDMA memory-registration tests involving large mappings can help validate functional behavior after patching, but production exploit-style testing should be avoided because failure modes may include kernel panic or data corruption.

Typical attack path

1. Gain local code execution on a Linux system with RDMA-capable hardware or RDMA kernel modules loaded.
2. Obtain permission to access RDMA user-space device interfaces such as /dev/infiniband/uverbs* or run inside a container granted RDMA device access.
3. Use RDMA APIs to register a very large memory region that results in IOMMU-backed scatter-gather mappings with blocks at or above 4 GB.
4. Trigger the vulnerable RDMA umem block-iteration path so the kernel truncates address values and calculates incorrect DMA addresses.
5. Initiate RDMA activity against the malformed mapping, causing invalid DMA behavior, memory corruption, IOMMU faults, data corruption, or a kernel crash.

How to detect it

There are no unique public indicators that reliably prove exploitation of this vulnerability. To investigate possible prior exploitation, collect and review kernel logs, system journal logs, hypervisor or host logs, IOMMU fault logs, RDMA driver logs, and crash dumps from RDMA-enabled systems. Look for kernel oops, panic, IOMMU/DMAR faults, invalid DMA reports, RDMA memory-registration failures, or sudden crashes of workloads using ibverbs, RoCE, InfiniBand, or RDMA storage paths. Correlate those events with local users, batch jobs, containers, or processes that had access to /dev/infiniband/uverbs* and performed unusually large memory registrations. On containerized systems, review runtime audit logs and Kubernetes or orchestrator events for RDMA device passthrough to untrusted workloads. Because the vulnerability may manifest as instability or corruption rather than a clean exploit trace, absence of these artifacts does not prove absence of exploitation.

What your security team should do

• Prioritize patching Linux systems with RDMA-capable NICs, InfiniBand, RoCE, storage fabrics, HPC workloads, or virtualization/container platforms that expose RDMA devices to users or workloads.
• Inventory systems with RDMA hardware, loaded RDMA kernel modules, or /dev/infiniband device nodes to determine practical exposure.
• Restrict RDMA device access to trusted users and workloads only; remove RDMA device passthrough from untrusted containers and enforce device cgroup controls.
• Monitor kernel, IOMMU, and RDMA driver logs for unusual faults, kernel oops events, panics, or RDMA registration failures involving large memory mappings.
• Treat unexplained crashes or data corruption on RDMA-enabled systems as potentially security-relevant until patched and investigated.
• Track distribution advisories for fixed kernel versions because the provided input does not include exact per-package fixed versions.
• Given the low EPSS score, no KEV listing, and no known exploit maturity, schedule remediation according to kernel-risk policy, but accelerate for multi-user RDMA systems and environments that host untrusted workloads.