Re: [PATCH 1/4] RDMA/rxe: Fix u64 iova+length overflow in mr_check_range

[Greg KH <greg@kroah.com>]

On Thu, May 21, 2026 at 07:44:08PM +0000, Tymbark7372 wrote:
> In mr_check_range(), the IB_MR_TYPE_USER and IB_MR_TYPE_MEM_REG case
> computes both iova + length and mr->ibmr.iova + mr->ibmr.length without
> overflow check.  Both iova (u64) and length (size_t) are 64-bit on
> 64-bit platforms.  An attacker setting iova = 0xFFFFFFFFFFFFFC00 and
> length = 0x400 wraps the sum to 0, so the bound check
> "iova + length > mr->ibmr.iova + mr->ibmr.length" passes.
> 
> After the bypass, rxe_mr_iova_to_index() computes a huge index value;
> WARN_ON(idx >= mr->nbuf) fires but does not abort, and
> rxe_mr_copy_xarray() then dereferences page_info[huge_idx], an
> attacker-controlled out-of-bounds slot.  In the RXE_TO_MR_OBJ
> direction this becomes an OOB write of attacker payload bytes through
> info->page + info->offset.
> 
> Use check_add_overflow() on both ends to reject any iova/length pair
> that wraps.  Also explicitly scope the local declarations introduced
> by the helper variables.
> 
> Reachable from any unprivileged local process with
> /dev/infiniband/uverbs0 open (world-rw on distros that ship the
> rdma-core udev rules) and from an unauthenticated remote peer over
> UDP/4791 (RoCEv2) when the target rkey/QPN are known.  Reproduced on
> v7.1.0-rc3 + KASAN with a single ibv_post_send(IBV_WR_RDMA_WRITE) and
> the wrap iova above; the kernel oopses in rxe_mr_copy+0x20d after
> WARN at rxe_mr_iova_to_index+0x135.
> 
> Site A in rxe_resp.c (check_rkey()) reaches mr_check_range() with
> attacker iova as well, so this patch also closes that path; Site B
> (duplicate_request, also in rxe_resp.c) has an independent inline
> check that wraps and is fixed in patch 3 of this series.
> 
> Fixes: 8700e3e7c485 ("Soft RoCE driver")
> Cc: stable@vger.kernel.org # v4.8+
> Reported-by: Tymbark7372 <tymbark7372@proton.me>
> Signed-off-by: Tymbark7372 <tymbark7372@proton.me>

We need a real name for the From: and signed-off-by line, and no need
for the duplicate reported-by line.

thanks,

greg k-h