All of lore.kernel.org
 help / color / mirror / Atom feed
From: Willy Tarreau <w@1wt.eu>
To: Zhu Yanjun <yanjun.zhu@linux.dev>
Cc: AYS <ays511.kr@gmail.com>,
	zyjzyj2000@gmail.com, linux-rdma@vger.kernel.org,
	security@kernel.org
Subject: Re: Subject: [PATCH] RDMA/rxe: bound the ODP page index against the umem in rxe_check_pagefault()
Date: Wed, 30 Sep 2026 21:17:41 +0200	[thread overview]
Message-ID: <ar1gVXr1ZXb52_uI@1wt.eu> (raw)
In-Reply-To: <81f485db-bd4a-4508-8e1a-0c97ffd418a6@linux.dev>

On Wed, Sep 30, 2026 at 09:52:30AM -0700, Zhu Yanjun wrote:
> 
> ? 2026/9/30 7:01, AYS ??:
> > An ODP MR's page array map.pfn_list[] is sized from the umem's start, but
> > rxe_check_pagefault() indexes it with an iova taken relative to that start
> > while the access was range-checked against the MR's iova (ibmr.iova).
> > reg_mr
> > only requires start and hca_va to share a page offset, so a user can
> > register
> > with hca_va = start + N*PAGE, and the index skew (hca_va - start) >>
> > PAGE_SHIFT then lands out of bounds of pfn_list[], which is read with no
> > bound
> > check. An unprivileged local user reaches this with a single RDMA
> > operation on
> > a self-connected rxe QP: observed as a KASAN slab-out-of-bounds read
> > and, when
> > the out-of-bounds qword looks like a writable HMM pfn, a write into an
> > attacker-influenced page.
> > 
> > Reject an index that leaves the umem and force the fault path, which
> > fails the
> > out-of-range access via the umem range check in
> > ib_umem_odp_map_dma_and_lock(). The downstream pfn_list[] users
> > (__rxe_odp_mr_copy() and the atomic helpers) run only after a successful
> > map,
> > so this check protects them as well.
> > 
> > Fixes: 2fae67ab63db ("RDMA/rxe: Add support for Send/Recv/Write/Read
> > with ODP")
> > Signed-off-by: Youngsung Ahn <ays511.kr@gmail.com>
> > ---
> > Notes (not part of the commit):
> > Reproduced on a KASAN x86-64 build of 7.3-rc4 as uid 1000; the data-only
> > write
> > primitive was used to reach uid 0 on a fully hardened build.
> > drivers/infiniband/sw/rxe/ is unchanged between 7.3-rc4 (93f51579e7df) and
> > mainline 551c722f4080 (2026-09-29) and rdma for-next, so both are
> > affected.
> > Compile-tested (KASAN+RDMA_RXE), not runtime-tested. Found through
> > AI-assisted
> > review; per Documentation/process/security-bugs.rst this is public and a
> > reproducer can be shared on request. A maintainer may prefer to also index
> > relative to ibmr.iova (as the non-ODP rxe_mr_iova_to_index() does) so
> > legitimately skewed MRs keep working; this patch takes the minimal, safe
> > route.
> > 
> >  drivers/infiniband/sw/rxe/rxe_odp.c | 5 +++++
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/drivers/infiniband/sw/rxe/rxe_odp.c
> > b/drivers/infiniband/sw/rxe/rxe_odp.c
> > index ab21b620e94c..07a30c60fc62 100644
> > --- a/drivers/infiniband/sw/rxe/rxe_odp.c
> > +++ b/drivers/infiniband/sw/rxe/rxe_odp.c
> > @@ -136,6 +136,11 @@ static inline bool rxe_check_pagefault(struct
> > ib_umem_odp *umem_odp, u64 iova,
> >   while (addr < iova + length) {
> >   idx = (addr - ib_umem_start(umem_odp)) >> umem_odp->page_shift;
> > 
> > + if (idx >= ib_umem_odp_num_pages(umem_odp)) {
> > + need_fault = true;
> > + break;
> > + }
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/coding-style.rst?h=v7.3-rc5
> 
> Please follow coding-style.rst to rewrite the above code snippet, then
> resend this commit.

I think it's not a coding style issue but an email encoding issue. Please
refer to Documentation/process/email-clients.rst to figure how to fix the
mailer's setup.

Willy

           reply	other threads:[~2026-09-30 19:17 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <81f485db-bd4a-4508-8e1a-0c97ffd418a6@linux.dev>]

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=ar1gVXr1ZXb52_uI@1wt.eu \
    --to=w@1wt.eu \
    --cc=ays511.kr@gmail.com \
    --cc=linux-rdma@vger.kernel.org \
    --cc=security@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.