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

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