> Does this bounds check allow processing of stale memory? It does, and 3/3 of this series stops it. This patch bounds by the size of the buffer the message landed in; 3/3 copies the tail of the message into the queue entry and bounds by its length instead.
The bound in this patch never fires on a link with a shared v2 receive buffer. It works out at 507 rkeys for ADD_LINK and 2046 for DELETE_RKEY, and the min_t() above it has already capped both at 255. I measured a 44-byte DELETE_RKEY_V2 declaring 255 rkeys: mainline and this patch draw the same response, and in two of the four exchanges an rkey read past the message was live and was deleted. With 3/3 applied the response reports 9. It does fire on a link without that buffer, where it becomes 9. That is the out-of-bounds read this patch fixes, and why it carries Cc: stable while 3/3 does not. Best regards, Yehyeong Lee
