CVE-2026-53187: Linux Kernel Privilege Escalation Issue

CVE-2026-53187 Overview

CVE-2026-53187 is an out-of-bounds read vulnerability in the Linux kernel's RDMA (Remote Direct Memory Access) core subsystem. The flaw resides in the DMA handle (DMAH) allocation path, where the cpu_id attribute supplied by user space through UVERBS_ATTR_ALLOC_DMAH_CPU_ID is passed directly to cpumask_test_cpu() without validating that the value is within the valid CPU range defined by nr_cpu_ids. An unprivileged local user can supply a crafted cpu_id to trigger an out-of-bounds read of the cpumask bitmap. The vulnerability was reported by the Smatch static analyzer and has been patched upstream.

Critical Impact
On kernels built with CONFIG_DEBUG_PER_CPU_MAPS and panic_on_warn, a malicious cpu_id triggers WARN_ON_ONCE() in cpumask_check(), converting bad user input into a kernel panic and system reboot.

Affected Products

Linux kernel RDMA/core subsystem (uverbs DMAH allocation interface)
Linux kernel builds exposing UVERBS_ATTR_ALLOC_DMAH_CPU_ID to user space
Kernels with CONFIG_DEBUG_PER_CPU_MAPS enabled are additionally susceptible to denial of service via panic_on_warn

Discovery Timeline

2026-06-25 - CVE-2026-53187 published to NVD
2026-06-25 - Last updated in NVD database

Technical Details for CVE-2026-53187

Vulnerability Analysis

The vulnerability exists in the RDMA core's DMAH allocation handler. When user space invokes the uverbs interface to allocate a DMA handle, it can specify a target CPU via the UVERBS_ATTR_ALLOC_DMAH_CPU_ID attribute. The kernel forwards this attribute directly to cpumask_test_cpu() without comparing it against nr_cpu_ids, the upper bound of valid CPU indices on the running system.

The helper cpumask_test_cpu() expands to test_bit(cpu, cpumask_bits(mask)), which indexes the underlying bitmap at offset cpu_id / BITS_PER_LONG. Without a bounds check, a large or negative-interpreted cpu_id reads memory outside the cpumask bitmap. This results in an out-of-bounds read [CWE-125] of kernel memory adjacent to the cpumask structure.

When the kernel is compiled with CONFIG_DEBUG_PER_CPU_MAPS, the same path also invokes cpumask_check(), which emits WARN_ON_ONCE() for invalid CPU indices. Systems configured with panic_on_warn convert this warning into a full kernel panic, providing a reliable local denial-of-service primitive.

Root Cause

The root cause is missing input validation on a user-controlled attribute. The DMAH allocation code in drivers/infiniband/core consumed the cpu_id value from the uverbs attribute parser and used it directly in a bitmap indexing operation. No if (cpu_id >= nr_cpu_ids) guard existed prior to the fix.

Attack Vector

A local user with access to an RDMA /dev/infiniband/uverbsN device node can issue an ALLOC_DMAH uverbs command with an out-of-range cpu_id. The attacker does not need elevated privileges beyond access to the RDMA character device, which is typically granted to users in groups that interact with InfiniBand or RoCE hardware. The result is either an out-of-bounds read of kernel memory or, on debug-enabled hardened kernels, a host reboot.

The upstream fix rejects any cpu_id that is not smaller than nr_cpu_ids with -EINVAL before it reaches cpumask_test_cpu(). See the kernel commit 0efbb6b54ff5, commit 323c98a4ff06, and commit bd5e818be796 for the patched code paths.

Detection Methods for CVE-2026-53187

Indicators of Compromise

Unexpected kernel WARN_ON_ONCE messages referencing cpumask_check in dmesg or journalctl -k output
Unscheduled host reboots on systems with CONFIG_DEBUG_PER_CPU_MAPS and panic_on_warn=1
Processes opening /dev/infiniband/uverbs* and issuing ALLOC_DMAH ioctls with anomalous parameters

Detection Strategies

Audit kernel logs for WARNING: CPU: traces originating in cpumask_check or RDMA uverbs code paths
Enable kernel auditd rules covering open and ioctl syscalls on /dev/infiniband/uverbs* devices to baseline legitimate RDMA usage
Monitor systems running kernel versions predating the upstream RDMA/core validation fix for absence of the patch

Monitoring Recommendations

Forward kernel ring buffer and audit logs to a centralized SIEM and alert on cpumask or RDMA uverbs warnings
Track kernel crash dumps and kdump artifacts for panics referencing ib_uverbs_handler_UVERBS_METHOD_DMAH_ALLOC
Inventory hosts exposing RDMA devices to unprivileged users and prioritize them for patching

How to Mitigate CVE-2026-53187

Immediate Actions Required

Apply stable kernel updates containing the upstream commits 0efbb6b54ff5, 323c98a4ff06, and bd5e818be796
Restrict access to /dev/infiniband/uverbs* device nodes to trusted users and service accounts only
On hosts where RDMA is not required, unload InfiniBand modules such as ib_uverbs and ib_core

Patch Information

The fix adds a bounds check that rejects any cpu_id greater than or equal to nr_cpu_ids with -EINVAL before the value reaches cpumask_test_cpu(). The patch is available across stable trees through the three referenced kernel.org commits. Distribution vendors backport these commits into their long-term support kernels. Verify your running kernel against the changelog of your distribution's security advisory before declaring the system patched.

Workarounds

Set permissive mode off and tighten udev rules so that only members of a dedicated rdma group can open uverbs devices
Disable panic_on_warn on debug-enabled kernels to prevent the warning path from causing reboots, while accepting that the underlying out-of-bounds read remains
Where RDMA is not in use, blacklist InfiniBand kernel modules via /etc/modprobe.d/ to remove the attack surface entirely

bash

# Configuration example: restrict RDMA uverbs access via udev
# /etc/udev/rules.d/90-rdma-restrict.rules
KERNEL=="uverbs*", SUBSYSTEM=="infiniband_verbs", GROUP="rdma", MODE="0660"

# Optionally blacklist on hosts that do not need RDMA
# /etc/modprobe.d/blacklist-rdma.conf
blacklist ib_uverbs
blacklist ib_core