Re: [PATCH net v5 2/3] net/smc: bound the peer rkey counts in SMC-Rv2 LLC messages
Yehyeong Lee <[email protected]> Mon, 3 Aug 2026 12:41:05 +0900
| Newsgroups | org.kernel.vger.linux-hardening,dev.linux.lists.sashiko-reviews,org.kernel.vger.linux-kernel,org.kernel.vger.linux-rdma,org.kernel.vger.linux-s390,org.kernel.vger.netdev |
|---|---|
| Message-ID | <[email protected]> |
> 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