All of lore.kernel.org
 help / color / mirror / Atom feed
From: Leon Romanovsky <leon@kernel.org>
To: AYS <ays511.kr@gmail.com>
Cc: zyjzyj2000@gmail.com, linux-rdma@vger.kernel.org, security@kernel.org
Subject: Re: [PATCH] RDMA/rxe: bound the ODP page index against the umem in rxe_check_pagefault()
Date: Thu, 1 Oct 2026 19:01:19 +0300	[thread overview]
Message-ID: <20261001160119.GQ3401365@unreal> (raw)
In-Reply-To: <CAPAqSgYP5tNonJb4VRLBt_34R8rcdc-gTB_jjmT221FqW18hmQ@mail.gmail.com>

On Thu, Oct 01, 2026 at 12:15:18AM +0900, AYS wrote:
> 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;
> + }
> +
>   if ((umem_odp->map.pfn_list[idx] & access) != access) {
>   need_fault = true;
>   break;

Please stop sending emails about RXE to security@ ML and use proper
email client to communicate with ML.

Thanks

> --
> 2.43.0
> 

  reply	other threads:[~2026-10-01 16:01 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-30 15:15 [PATCH] RDMA/rxe: bound the ODP page index against the umem in rxe_check_pagefault() AYS
2026-10-01 16:01 ` Leon Romanovsky [this message]
  -- strict thread matches above, loose matches on Subject: below --
2026-09-30 17:51 Youngsung Ahn
2026-09-30 18:03 ` sashiko-bot
2026-09-30 19:25 ` Willy Tarreau

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=20261001160119.GQ3401365@unreal \
    --to=leon@kernel.org \
    --cc=ays511.kr@gmail.com \
    --cc=linux-rdma@vger.kernel.org \
    --cc=security@kernel.org \
    --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.