CVE-2026-98354: RDMA/mad: Fix receive buffer leak when PKey enforcement fails
In the Linux kernel, the following vulnerability has been resolved:
RDMA/mad: Fix receive buffer leak when PKey enforcement fails
ibmadcompleterecv() initializes madrecvwc->rmpplist and then runs ibmadenforcesecurity() before linking recvbuf onto that list. On failure it calls ibfreerecvmad(), which only walks rmpplist and frees the ibmadprivate of every buffer found there. As the list is still empty at that point, nothing is freed at all.
The caller cannot clean up either: ibmadrecvdone() sets recv to NULL right after ibmadcompleterecv() returns, assuming the MAD layer took ownership of the buffer. Every MAD that fails the PKey check therefore leaks one ibmadprivate (about 300 bytes per IB port MAD, ~2K for OPA), and a remote node can trigger this repeatedly by sending MADs with a wrong PKey.
Link recvbuf onto rmpplist right after the list is initialized, so the error path has something to free.
Affected Software
Event History
Frequently Asked Questions
Who can trigger the leak?
A remote node that can send RDMA MADs to an affected IB or OPA port can repeatedly trigger the leak by sending MADs with an incorrect PKey.
What happens when PKey enforcement rejects a MAD?
Each rejected MAD leaks one ib_mad_private allocation because the receive buffer is not yet linked to the cleanup list. The leak is approximately 300 bytes per IB port MAD and about 2 KB for OPA.
Can the caller reclaim the leaked receive buffer after the security check fails?
No. The receive completion path clears its receive pointer after ib_mad_complete_recv() returns because it assumes the MAD layer has taken ownership, leaving no caller-side cleanup path.