CVE-2026-53187

What it actually does

This vulnerability is an improper input validation flaw in the Linux kernel RDMA uverbs DMAH allocation path. A user-supplied CPU identifier provided through UVERBS_ATTR_ALLOC_DMAH_CPU_ID is passed to cpumask_test_cpu() without first verifying that it is less than nr_cpu_ids. An out-of-range value can cause an out-of-bounds read from the cpumask bitmap. On kernels built with CONFIG_DEBUG_PER_CPU_MAPS, the invalid CPU value can trigger a WARN_ON_ONCE() in cpumask_check(); if panic_on_warn is enabled, that warning can escalate into a kernel panic and system reboot. The practical impact is local denial of service on systems exposing RDMA uverbs functionality to an attacker-controlled local process; the description does not indicate privilege escalation or remote code execution.

Why it matters to the business

The main business risk is disruption of Linux systems that use or expose RDMA functionality, especially high-performance computing, storage, virtualization, AI/ML, database, or low-latency networking workloads. A local user or compromised local process may be able to crash or reboot affected systems if debug CPU map checks and panic-on-warning behavior are enabled, causing workload interruption, failed jobs, service instability, or availability incidents. This issue is not currently in CISA KEV, is not known to be used in ransomware campaigns, and has a very low EPSS score, so remediation should be prioritized based on local exposure to RDMA devices, multi-user access, and the operational criticality of affected Linux hosts rather than broad internet-scale exploitation risk.

How an attack unfolds

An attacker first needs the ability to run code locally on an affected Linux system and interact with the RDMA uverbs interface. They then open the relevant RDMA userspace device and invoke the DMAH allocation path with a crafted UVERBS_ATTR_ALLOC_DMAH_CPU_ID value that is outside the valid CPU range for the running kernel. Because the kernel fails to validate that the supplied CPU ID is smaller than nr_cpu_ids before calling cpumask_test_cpu(), the value is used to index beyond the intended cpumask bitmap. On many systems this may result only in an out-of-bounds read with limited visible impact, but on kernels compiled with CONFIG_DEBUG_PER_CPU_MAPS the invalid CPU index can trigger a kernel warning. If panic_on_warn is configured, that warning becomes a kernel panic, forcing a reboot and creating a local denial-of-service condition.

How to fix it

Apply a kernel update that includes the RDMA/core fix validating UVERBS_ATTR_ALLOC_DMAH_CPU_ID against nr_cpu_ids before use. Because no specific affected product list or fixed package versions were provided, use the security advisories and kernel packages from the relevant Linux distribution or kernel vendor and confirm that the patch rejects CPU IDs greater than or equal to nr_cpu_ids with -EINVAL. Where immediate patching is not possible, reduce exposure by restricting local shell access, limiting access to RDMA device files such as /dev/infiniband/uverbs*, disabling or unloading unused RDMA-related modules where operationally safe, and reviewing whether kernel.panic_on_warn is enabled on systems where availability is critical. Avoid disabling safety/debug controls as a primary fix; the durable remediation is the kernel input validation patch.

How to confirm the fix worked

Confirm the running kernel version includes the vendor fix for this vulnerability or the upstream RDMA/core change that checks cpu_id against nr_cpu_ids during DMAH allocation. Validate package status using the Linux distribution's package manager and security advisory metadata, then reboot into the patched kernel if required. Check RDMA exposure by looking for loaded RDMA modules and userspace device nodes such as /dev/infiniband/uverbs*. Confirm the runtime kernel is the patched one with uname -a or equivalent asset inventory data. For mitigation validation, verify that access permissions to RDMA device nodes are restricted to intended users and groups, and review sysctl kernel.panic_on_warn to understand whether kernel warnings can still cause automatic reboots. In a controlled non-production test environment, a malformed DMAH allocation using an out-of-range CPU ID should return -EINVAL rather than causing a warning, panic, or crash.

Typical attack path

1. Gain local code execution or access to a local account on an affected Linux system.
2. Confirm that RDMA userspace interfaces are present and accessible, such as uverbs devices under /dev/infiniband/.
3. Open the RDMA uverbs device from a local process.
4. Submit a DMAH allocation request containing a crafted UVERBS_ATTR_ALLOC_DMAH_CPU_ID value greater than or equal to nr_cpu_ids.
5. Trigger cpumask_test_cpu() with the out-of-range CPU value, causing an out-of-bounds cpumask bitmap read.
6. On kernels with CONFIG_DEBUG_PER_CPU_MAPS, trigger a kernel warning through cpumask_check().
7. If panic_on_warn is enabled, cause a kernel panic and system reboot.

How to detect it

To determine whether this was already exploited, review kernel and system logs from affected Linux hosts for RDMA uverbs activity followed by CPU mask warnings, kernel warnings, panics, oopses, or unexpected reboots. Relevant sources include journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, persistent pstore/ramoops records, kdump/vmcore artifacts, and crash dump analysis. Focus on events involving cpumask_check(), cpumask_test_cpu(), test_bit(), RDMA/core, ib_uverbs, uverbs, DMAH allocation, WARN_ON_ONCE, and panic_on_warn. Correlate any warning or panic with local process accounting, auditd, eBPF telemetry, shell history, job scheduler records, container runtime logs, and authentication logs to identify which local user or workload accessed /dev/infiniband/uverbs* immediately before the event. There are no known remote network indicators or named threat actors associated with this issue based on the provided data; detection should be host-forensic and kernel-log focused.

• /dev/infiniband/uverbs
• /dev/infiniband/uverbs0
• UVERBS_ATTR_ALLOC_DMAH_CPU_ID
• ALLOC_DMAH_CPU_ID
• DMAH
• RDMA/core
• ib_uverbs
• uverbs
• cpumask_check
• cpumask_test_cpu
• CONFIG_DEBUG_PER_CPU_MAPS
• WARN_ON_ONCE
• panic_on_warn
• kernel panic
• Kernel panic - not syncing
• Out of bounds
• out-of-bounds
• nr_cpu_ids
• test_bit

What your security team should do

• Inventory Linux systems with RDMA hardware, RDMA kernel modules, or /dev/infiniband/uverbs* device nodes and prioritize them for assessment.
• Patch affected systems using vendor-provided kernel updates, then reboot to ensure the fixed kernel is active.
• Prioritize multi-user, HPC, virtualization, storage, AI/ML, and database systems where local users or workloads can access RDMA uverbs devices.
• Restrict access to RDMA device nodes to only required service accounts and trusted users until patching is complete.
• Review kernel.panic_on_warn settings on critical systems and understand whether warnings can trigger automatic reboots; adjust only after considering operational and security tradeoffs.
• Monitor kernel logs for cpumask, RDMA/uverbs, WARN_ON, and kernel panic messages that may indicate attempted exploitation or crash testing.
• Because exploitation is local and public exploit maturity is currently reported as none, treat this as a targeted availability risk rather than an internet-facing emergency unless local untrusted users or shared compute workloads are present.