Linux kernel InfiniBand/RDMA uAPI write() handlers (ib_uverbs, rdma_ucm, ib_ucm, ib_umad): The whole drivers/infiniband

Impact

The whole drivers/infiniband stack used write() as a bidirectional ioctl - the caller passes a response pointer inside the write buffer and the kernel writes the reply structure there. Reached through splice() or a writable pipe/aio path, that response pointer is resolved against kernel address space instead of user address space, giving a tenant an arbitrary kernel-memory write from any RDMA character device it can open. Same blast radius as the uverbs registration bug but a wider surface: rdma_ucm, ib_ucm and ib_umad are all affected, so even a tenant with only the connection-manager or MAD device exposed gets the primitive.

Who can reach it

Local, unprivileged - write access to any /dev/infiniband/* node (uverbsN, rdma_cm, ucmN, umadN). Standard for RDMA-enabled tenant containers.

What to do

Kernel upgrade to 4.5.3+ or a vendor backport of commit e6bd18f57aad1a2d1ef40e646d03ed0f2515c9e3 (IB/security: restrict use of the write() interface), which detects and denies the suspicious write paths. Requires a rolling reboot; the fix touches the uAPI entry points so it cannot be hot-patched safely. Note the upstream commit is explicitly a stopgap - the durable fix was moving the RDMA uAPI to a structured ioctl() interface in later kernels, so a fleet stuck on a pre-4.5 vendor kernel is relying on a band-aid.

References