Medium [CVE-2026-68425] Drop unmatched RMPP responses before reassembly

In the Linux kernel, the following vulnerability has been resolved: IB/mad: Drop unmatched RMPP responses before reassembly Kernel-handled RMPP receive processing starts reassembly for active DATA responses before the response is matched to an outstanding send.

The normal match happens later, after ib_process_rmpp_recv_wc() has either assembled a complete message or consumed the segment. That ordering lets an unsolicited response that routes to a kernel RMPP agent by the high TID bits allocate or extend RMPP receive state before the full TID and source address are checked against a real request.

A reordered burst can therefore reach the receive-side insertion path even though the response would not match any send. The matcher already checks the full TID, management class and source address/GID against the agent wait, backlog and in-flight send lists.

If there is no match, drop the response without creating RMPP state. This leaves the RMPP window behavior unchanged and only rejects responses that have no corresponding request.

A flaw was found in the Linux kernel's InfiniBand (IB) Management Datagram (mad) component. A remote attacker could exploit this vulnerability by sending unsolicited Reliable Multicast Packet Protocol (RMPP) responses.