Linux kernel InfiniBand MAD layer (kernel RMPP receive reassembly, ib_mad): This is a pre-authentication flaw on the

Impact

This is a pre-authentication flaw on the InfiniBand management plane. The kernel started RMPP reassembly for an inbound DATA response purely on the high bits of the transaction ID, before matching the full TID and source address against any outstanding request. An unsolicited response injected onto the fabric can therefore allocate and extend kernel RMPP receive state that no local agent ever asked for - reassembly-state exhaustion and management-agent disruption driven by a peer on the same IB subnet, with no credential of any kind. On a shared fabric the adjacent 'peer' can be another tenant's node, so this is a cross-tenant reach into the layer that carries subnet-manager traffic.

Who can reach it

Adjacent network - any host able to emit MADs onto the same InfiniBand subnet, unauthenticated. That includes every compute node on a shared fabric, and any tenant that has been given umad access on such a node.

What to do

Kernel update that drops unmatched RMPP DATA responses before reassembly begins. Compensating controls are weak here: IB partitioning (pkeys) does not separate the management class, and M_Key protection only guards SMPs, not the GMP/RMPP path this affects. Patch the fabric-attached nodes.

References