Linux kernel RDMA core (UVERBS_ATTR_ALLOC_DMAH_CPU_ID, DMA handle allocation): The cpu_id a tenant passes when

CVSS 7.1CVE-2026-53187Firmware, BMC & network fabriccurated

Impact

The cpu_id a tenant passes when allocating a DMA handle goes straight into cpumask_test_cpu() with no range check, so it becomes an unbounded bit index into the cpumask bitmap - an out-of-bounds kernel read at an offset the tenant chooses. On kernels built with CONFIG_DEBUG_PER_CPU_MAPS the same input trips a WARN_ON_ONCE, which on a panic_on_warn fleet (common in hyperscale and neocloud images, because operators want crash dumps rather than silent corruption) converts an unprivileged ioctl into a node reboot - one tenant evicting every other job on the box.

Who can reach it

Local ioctl on /dev/infiniband/uverbs* by any RDMA-capable tenant. Unprivileged.

What to do

Kernel update rejecting cpu_id values that are not below nr_cpu_ids. If you run panic_on_warn fleet-wide, note that this class of bug turns any WARN reachable from an unprivileged syscall into a tenant-triggered node kill - worth reviewing that policy alongside the patch.

References

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0efbb6b54ff56300867027d8e0800d0e32226a20 https://git.kernel.org/pub/scm/linux/security/vulns.git/tree/cve/published/2026/CVE-2026-53187.json

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.