From: Zhu Yanjun <yanjun.zhu@linux.dev>
To: Norbert Szetei <norbert@doyensec.com>,
linux-rdma@vger.kernel.org,
"yanjun.zhu@linux.dev" <yanjun.zhu@linux.dev>
Cc: Zhu Yanjun <zyjzyj2000@gmail.com>, Jason Gunthorpe <jgg@ziepe.ca>,
Leon Romanovsky <leon@kernel.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] RDMA/rxe: Reject prefetch of a non-ODP MR
Date: Thu, 27 Aug 2026 12:12:22 -0700 [thread overview]
Message-ID: <1cd5be49-6946-4010-8539-e8d015f23201@linux.dev> (raw)
In-Reply-To: <521D5E74-89E3-43C0-81C7-AC0BE52591E7@doyensec.com>
在 2026/8/27 3:51, Norbert Szetei 写道:
> rxe_ib_advise_mr_prefetch() and rxe_ib_prefetch_sg_list() look up the MR
> by lkey and hand it to rxe_odp_do_pagefault_and_lock() without checking
> that it is an ODP MR. That path runs to_ib_umem_odp() on mr->umem, and
> for a non-ODP MR mr->umem is a plain struct ib_umem from ib_umem_get(),
> so the container_of() in to_ib_umem_odp() lands past the end of the
> object and ib_umem_odp_map_dma_and_lock() reads its ib_umem_odp fields
> out of bounds.
>
> lookup_mr() validates the lkey, PD, access and state but not the MR
> type, and IB_UVERBS_ADVISE_MR_ADVICE_PREFETCH is accepted for any MR.
>
> BUG: KASAN: slab-out-of-bounds in ib_umem_odp_map_dma_and_lock+0x884/0x8a0
> Read of size 8 at addr ffff88810a3ebcf0 by task advi/921
> ib_umem_odp_map_dma_and_lock+0x884/0x8a0
> rxe_ib_advise_mr+0x543/0xad0
> ib_uverbs_handler_UVERBS_METHOD_ADVISE_MR+0x446/0x530
> ib_uverbs_cmd_verbs+0x2b3c/0x3b20
> ib_uverbs_ioctl+0x1e3/0x310
> Allocated by task 921:
> __ib_umem_get_va+0x13e/0xae0
> rxe_mr_init_user+0x2ae/0xb00
> rxe_reg_user_mr+0x337/0x510
> The buggy address belongs to the object at ffff88810a3ebc80
> which belongs to the cache kmalloc-96 of size 96
>
> Reject a non-ODP MR after lookup_mr() in both the synchronous and
> asynchronous prefetch arms.
>
> Fixes: 3576b0df1588 ("RDMA/rxe: Implement synchronous prefetch for ODP MRs")
> Cc: stable@vger.kernel.org
> Signed-off-by: Norbert Szetei <norbert@doyensec.com>
> ---
> drivers/infiniband/sw/rxe/rxe_odp.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/infiniband/sw/rxe/rxe_odp.c b/drivers/infiniband/sw/rxe/rxe_odp.c
> index e870efa7a0a3..5c9dde3501a0 100644
> --- a/drivers/infiniband/sw/rxe/rxe_odp.c
> +++ b/drivers/infiniband/sw/rxe/rxe_odp.c
> @@ -472,6 +472,11 @@ static int rxe_ib_prefetch_sg_list(struct ib_pd *ibpd,
> return -EINVAL;
> }
>
> + if (unlikely(!is_odp_mr(mr))) {
lookup_mr is a function specific to rxe. Renaming it to rxe_lookup_mr
would make this clearer.
When I first saw this function, I assumed it was a generic RDMA
function. After looking into the implementation, I realized that it is
specific to rxe. Therefore, I think rxe_lookup_mr would be a clearer and
more descriptive name.
Anyway, I think this commit is fine. Thanks a lot.
Reviewed-by: Zhu Yanjun yanjun.zhu@linux.dev
Zhu Yanjun > + rxe_put(mr);
> + return -EOPNOTSUPP;
> + }
> +
> if (advice == IB_UVERBS_ADVISE_MR_ADVICE_PREFETCH_WRITE &&
> !mr->umem->writable) {
> rxe_dbg_mr(mr, "missing write permission\n");
> @@ -536,6 +541,12 @@ static int rxe_ib_advise_mr_prefetch(struct ib_pd *ibpd,
> goto err;
> }
>
> + if (unlikely(!is_odp_mr(mr))) {
> + rxe_put(mr);
> + mr = ERR_PTR(-EOPNOTSUPP);
> + goto err;
> + }
> +
> work->frags[i].io_virt = sg_list[i].addr;
> work->frags[i].length = sg_list[i].length;
> work->frags[i].mr = mr;
next prev parent reply other threads:[~2026-08-27 19:12 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-27 10:51 [PATCH] RDMA/rxe: Reject prefetch of a non-ODP MR Norbert Szetei
2026-08-27 19:12 ` Zhu Yanjun [this message]
2026-09-01 7:56 ` Leon Romanovsky
2026-09-04 7:49 ` Norbert Szetei
2026-09-06 9:01 ` Leon Romanovsky
2026-09-13 11:53 ` Norbert Szetei
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1cd5be49-6946-4010-8539-e8d015f23201@linux.dev \
--to=yanjun.zhu@linux.dev \
--cc=jgg@ziepe.ca \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=norbert@doyensec.com \
--cc=zyjzyj2000@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.