Linux RDMA and InfiniBand development
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox