Linux kernel InfiniBand user MAD interface (ib_umad, /dev/infiniband/umad*): A process with access to the user MAD

Impact

A process with access to the user MAD character device can craft a write() whose declared MAD header size and RMPP header length disagree, driving the computed data_len negative. The negative length propagates into ib_create_send_mad(), where the padding calculation overshoots the segment size and produces a slab out-of-bounds memset in alloc_send_rmpp_list(). That is an attacker-influenced heap write from a device node that fabric-management tooling routinely leaves accessible, and the umad path is also the channel that speaks to the subnet manager - so heap control here sits next to the code that configures the IB fabric itself.

Who can reach it

Local write() to /dev/infiniband/umad*. Any container or user that has been granted the umad device - common on nodes running opensm, ibdiagnet, perfquery or any vendor fabric agent - can reach it without extra privilege.

What to do

Kernel update adding the explicit negative-data_len rejection in ib_umad_write(). Interim: audit which pods and which non-root users actually hold /dev/infiniband/umad* - in most clusters the answer should be 'only the fabric-management daemonset', and tightening that is a same-day change that does not need a reboot.

References