Linux kernel RDMA/uverbs: legacy write() bundle has no ioctl method element, causing a NULL dereference

UnscoredCVE-2026-89505Kernel, userspace & hypervisorcurated

Impact

The legacy uverbs write() path dispatches through a uverbs_api_write_method, but the uverbs_attr_bundle handed to provider code carries no ioctl method element. If malformed provider input makes the common uverbs validation code emit an error message, uverbs_get_handler_fn() dereferences the uninitialized method_elm pointer. On a GPU fleet the verbs character devices are what RDMA workloads - NCCL over RoCE or InfiniBand, GPUDirect RDMA, parallel filesystem clients - hold open, and on many clusters that means tenant containers have them mapped. A tenant that submits deliberately malformed verbs input crashes the host kernel, taking down every other tenant on a node that cannot be drained cheaply.

Who can reach it

Local user holding an open /dev/infiniband/uverbs* device, which in practice means any tenant pod granted RDMA access. Authenticated in the sense that device access is required; no network path.

What to do

Update the host kernel to a stable release that initializes method_elm for legacy bundles and returns NULL when no ioctl method is present (two stable commits linked), then reboot each node. Interim mitigation is to stop exposing the uverbs devices to untrusted workloads, which for most RDMA tenants removes the capability they came for. No fixed release number is given.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-89505 https://git.kernel.org/stable/c/60a42d510113f46de47e86a84bf5758597644487 https://git.kernel.org/stable/c/edae84e5461749ed9adf9fcf5c6e075381040ac3

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.