From: Leon Romanovsky <leon@kernel.org>
To: norbert@doyensec.com
Cc: Zhu Yanjun <zyjzyj2000@gmail.com>, Jason Gunthorpe <jgg@ziepe.ca>,
Bob Pearson <rpearsonhpe@gmail.com>,
Daisuke Matsuda <dskmtsd@gmail.com>,
linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org,
Zhu Yanjun <yanjun.zhu@linux.dev>,
stable@vger.kernel.org
Subject: Re: [PATCH v2 0/2] RDMA/rxe: fix ADVISE_MR prefetch on non-ODP MRs
Date: Fri, 18 Sep 2026 15:50:25 +0300 [thread overview]
Message-ID: <20260918125025.GY13683@unreal> (raw)
In-Reply-To: <20260913-rxe-advise-mr-v2-v2-0-b806c789871c@doyensec.com>
On Sun, Sep 13, 2026 at 01:45:14PM +0200, Norbert Szetei via B4 Relay wrote:
> ADVISE_MR prefetch on a plain MR runs to_ib_umem_odp() on a struct
> ib_umem, giving a KASAN slab-out-of-bounds read in
> ib_umem_odp_map_dma_and_lock() (splat in patch 2).
>
> v1 checked is_odp_mr() after lookup_mr(). Leon asked for lookup_mr() to
> do the check itself, off mr->access. That only holds once mr->access
> cannot disagree with the umem, so patch 1 stops the two paths that
> assign mr->access after registration from touching IB_ACCESS_ON_DEMAND,
> and patch 2 passes the flag to lookup_mr() in both prefetch arms.
>
> Patch 1 adds another failure return to rxe_rereg_user_mr(), so it
> depends on ae36a5b609ae ("RDMA/rxe: validate access flags before
> swapping the MR's PD"), which moved the validation above the
> mr->ibmr.pd swap. The series is based on for-rc.
Please rebase it on top of for-next.
Thanks
prev parent reply other threads:[~2026-09-18 12:50 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-13 11:45 [PATCH v2 0/2] RDMA/rxe: fix ADVISE_MR prefetch on non-ODP MRs Norbert Szetei via B4 Relay
2026-09-13 11:45 ` Norbert Szetei
2026-09-13 11:45 ` [PATCH v2 1/2] RDMA/rxe: Reject IB_ACCESS_ON_DEMAND changes after MR creation Norbert Szetei via B4 Relay
2026-09-13 11:45 ` Norbert Szetei
2026-09-13 12:03 ` sashiko-bot
2026-09-13 11:45 ` [PATCH v2 2/2] RDMA/rxe: Reject prefetch of a non-ODP MR Norbert Szetei via B4 Relay
2026-09-13 11:45 ` Norbert Szetei
2026-09-13 11:58 ` sashiko-bot
2026-09-18 12:50 ` Leon Romanovsky [this message]
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=20260918125025.GY13683@unreal \
--to=leon@kernel.org \
--cc=dskmtsd@gmail.com \
--cc=jgg@ziepe.ca \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=norbert@doyensec.com \
--cc=rpearsonhpe@gmail.com \
--cc=stable@vger.kernel.org \
--cc=yanjun.zhu@linux.dev \
--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.