From nobody Fri Sep 25 12:04:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7103253B61F; Wed, 23 Sep 2026 14:44:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790174659; cv=none; b=D0oXPEzEvfXCplAG2PgMuEWXRmcllKtyDWDC/fBhgZ4X06q9zzEq6wQ/+tTrZE3blp1EjudgJ23fI91EsSTgMTijzwYXlCSDBNwY0p25RnX3sZEiBIjKBneTGxqRPSrw+1KY/aqFRhKRd03iH37qEHe3bUnM8J1jsH/RwxsX24w= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790174659; c=relaxed/simple; bh=JbK8SF6rj3FVILYqLYruw8+ndDVRZsJrV3Nb1yA+JnI=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=Q9qUQ6gcZ0+95xmGGBPMhNPBrz8Cyxe9K7AYuloaeEQIJBSK/s5xK0b2YRe7O8yf6fmmlcqlJtTYAYNUFfSQWgYtgXCRRblTz3LecDx7cZfS8dariJjFzTC3wAC7T8GfQL75/bTQDq6sG7JZGhsB3Dq6e8u/lsTCG3LySIKKdlE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=r9/q2UWr; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="r9/q2UWr" Received: by smtp.kernel.org (Postfix) with ESMTPS id 185CCC2BCB8; Wed, 23 Sep 2026 14:44:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1790174659; bh=JbK8SF6rj3FVILYqLYruw8+ndDVRZsJrV3Nb1yA+JnI=; h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From; b=r9/q2UWrVpzu9bnrG66b65BQNrtBIsu4IefFyeiUo49eOHkQPko0km6apyyrhsPrC QCZSk80UB47kbFN7pN+B17FASf7q5n5O3WPtBZdhxIvBvE6vQQeubnwd1Qol+7oKdM lXH00ntbNkKoRESCBCdpy5NbwlL7btlY0whbRydy/PlybpAz/DBPFI4daNECg4EGsN R/Ottnz4xrKo7viozSctGODI4hBAbX9eYlCyspuHYeKS2qk+InXZ+HDr2GvefSzkeG f7pFe9jUVqquqJzFwyJrimWLl6D3JnAQuwua1VbpQvK/9xe8w32I+cr85JdqjxMCh+ wsQfurytk43Xw== Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id E9803C9830B; Wed, 23 Sep 2026 14:44:18 +0000 (UTC) From: Norbert Szetei via B4 Relay Date: Wed, 23 Sep 2026 16:40:49 +0200 Subject: [PATCH v3 1/2] RDMA/rxe: Reject IB_ACCESS_ON_DEMAND changes after MR creation Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260923-rxe-advise-mr-v3-v3-1-95e1a4077e4d@doyensec.com> References: <20260923-rxe-advise-mr-v3-v3-0-95e1a4077e4d@doyensec.com> In-Reply-To: <20260923-rxe-advise-mr-v3-v3-0-95e1a4077e4d@doyensec.com> To: Zhu Yanjun , Jason Gunthorpe , Leon Romanovsky , Bob Pearson , Daisuke Matsuda Cc: linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org, Zhu Yanjun , stable@vger.kernel.org, Norbert Szetei X-Mailer: b4 0.16.0 X-Developer-Signature: v=1; a=ed25519-sha256; t=1790174657; l=2510; i=norbert@doyensec.com; s=20260913; h=from:subject:message-id; bh=GGDMNIMMFgavQyw+alW2k5m6GacCiuPCFvCSnkVJm7M=; b=YVBMCEN8W79y713DC9Z3JrPx/igouyNVpEHragpEpC0fyRvC9DqYZx1utrwToKNDkMF760FwG uIHrgrMpLJrADwyn0Ksj6a5RrUVK8rBAZZGS0u+yKyUx3yCF08vQMQr X-Developer-Key: i=norbert@doyensec.com; a=ed25519; pk=c6ZqJ+mhvi5FloJOiMJUcIPPjT7tczbglx5gruwpVi8= X-Endpoint-Received: by B4 Relay for norbert@doyensec.com/20260913 with auth_id=1029 X-Original-From: Norbert Szetei Reply-To: norbert@doyensec.com From: Norbert Szetei Whether an MR is an ODP MR is decided once, at registration time: rxe_reg_user_mr() picks rxe_odp_mr_init_user() over rxe_mr_init_user() based on IB_ACCESS_ON_DEMAND, and only the former builds an ib_umem_odp via ib_umem_odp_get(). The umem cannot change type afterwards, and is_odp_mr() reads mr->umem->is_odp. Two paths assign mr->access after that point and can leave it describing an MR type the umem does not have: rxe_rereg_user_mr() with IB_MR_REREG_ACCESS overwrites mr->access with the caller's value, and IB_ACCESS_ON_DEMAND is part of RXE_ACCESS_SUPPORTED_MR, so userspace can set the flag on a plain MR or clear it on an ODP MR while the umem stays what it was. rxe_reg_fast_mr() takes mr->access from the REG_MR work request unmasked and moves the MR to RXE_MR_STATE_VALID, on an MR that rxe_mr_init_fast() left with a NULL umem. Reject IB_ACCESS_ON_DEMAND in both, so mr->access carries the flag only for an MR that has an ODP umem and the flag can be used to identify one. Fixes: 544c7f62cf32 ("RDMA/rxe: Implement rereg_user_mr") Cc: stable@vger.kernel.org Signed-off-by: Norbert Szetei Reviewed-by: Zhu Yanjun --- drivers/infiniband/sw/rxe/rxe_mr.c | 6 ++++++ drivers/infiniband/sw/rxe/rxe_verbs.c | 6 ++++++ 2 files changed, 12 insertions(+) diff --git a/drivers/infiniband/sw/rxe/rxe_mr.c b/drivers/infiniband/sw/rxe= /rxe_mr.c index 875eceb55fdf..2afda5154dfb 100644 --- a/drivers/infiniband/sw/rxe/rxe_mr.c +++ b/drivers/infiniband/sw/rxe/rxe_mr.c @@ -795,6 +795,12 @@ int rxe_reg_fast_mr(struct rxe_qp *qp, struct rxe_send= _wqe *wqe) return -EINVAL; } =20 + /* an MR with no umem is never an ODP MR */ + if (unlikely(access & IB_ACCESS_ON_DEMAND)) { + rxe_dbg_mr(mr, "access =3D 0x%x requests ODP\n", access); + return -EINVAL; + } + mr->access =3D access; mr->lkey =3D key; mr->rkey =3D key; diff --git a/drivers/infiniband/sw/rxe/rxe_verbs.c b/drivers/infiniband/sw/= rxe/rxe_verbs.c index 96c7716057fe..21855274f63a 100644 --- a/drivers/infiniband/sw/rxe/rxe_verbs.c +++ b/drivers/infiniband/sw/rxe/rxe_verbs.c @@ -1331,6 +1331,12 @@ static struct ib_mr *rxe_rereg_user_mr(struct ib_mr = *ibmr, int flags, if (err) return ERR_PTR(err); =20 + if ((flags & IB_MR_REREG_ACCESS) && + ((access ^ mr->access) & IB_ACCESS_ON_DEMAND)) { + rxe_err_mr(mr, "cannot change IB_ACCESS_ON_DEMAND\n"); + return ERR_PTR(-EOPNOTSUPP); + } + if (flags & IB_MR_REREG_PD) { rxe_put(old_pd); rxe_get(pd); --=20 2.55.0 From nobody Fri Sep 25 12:04:12 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B0CED53C3C9; Wed, 23 Sep 2026 14:44:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790174659; cv=none; b=aqSXzvrlpucPrTvgTixJTSYEv7JF+b0o0EPdXHVdzgMEVdTOUoZPsmBSlibLsN4AFmRZyDfHy/4xBSh81MyTYT9BiB7eSWjy3sz+6JikXrbOPmYipYkBVxpPa2Xq0DOlf1nYckur47olblb6teCZY/voXZEPl7Abvs176c5aZKY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790174659; c=relaxed/simple; bh=EB63EaSZMCNY5nE3KWUV4Qnkrt4NrdgytM88dOQtn3c=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=kFJ4HbUtmCdxp0l7++FceN3bHOCFObWPgSi/aOEjrPD1RjXy4LzCzq+BeeawpzEW6rWgnsvI7q64Ev13ZOR4staf1+ZxB6ffBIotXOLLu+M7VXfrc3hJzgcyo42RAN8OBSlBgMAu4lMNaXgLgnHiN7zbcJl7Z3Zd5/YjJrPt4uA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=PSw8iiaB; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="PSw8iiaB" Received: by smtp.kernel.org (Postfix) with ESMTPS id 2EE04C2BCF7; Wed, 23 Sep 2026 14:44:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1790174659; bh=EB63EaSZMCNY5nE3KWUV4Qnkrt4NrdgytM88dOQtn3c=; h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From; b=PSw8iiaBjfiVoJDzbpGdW/D5xNAYBUugrGq1bj+IjUbwi/l30xG6YUTHosmtjWB9/ MOuvImdiu4JwhUgZTJ+dzODyMm6+qJmykV6GLQaK0wHlrCBVLmLHUBIChUOmqLVuCs XPryM9Nw50wZVZFyu+hc5nhmol61qWtlNxN57jI/lieo9IhNEGyrwR4disUZHeHPJz NKW2RZBQCszUn9YZqlxtB3iZGH96cQGa5UQzKZiGK3I15OP93soOFEv05xF1wRIjSb kdSz3VjexsUcJs6S7VO3uvnPB/VH48ySKbEedu30pX1QC+/ITEjK0P1SbvZzk1uIeQ KN4xXCI9Kxzag== Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 09061C9830E; Wed, 23 Sep 2026 14:44:19 +0000 (UTC) From: Norbert Szetei via B4 Relay Date: Wed, 23 Sep 2026 16:40:50 +0200 Subject: [PATCH v3 2/2] RDMA/rxe: Reject prefetch of a non-ODP MR Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260923-rxe-advise-mr-v3-v3-2-95e1a4077e4d@doyensec.com> References: <20260923-rxe-advise-mr-v3-v3-0-95e1a4077e4d@doyensec.com> In-Reply-To: <20260923-rxe-advise-mr-v3-v3-0-95e1a4077e4d@doyensec.com> To: Zhu Yanjun , Jason Gunthorpe , Leon Romanovsky , Bob Pearson , Daisuke Matsuda Cc: linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org, Zhu Yanjun , stable@vger.kernel.org, Norbert Szetei X-Mailer: b4 0.16.0 X-Developer-Signature: v=1; a=ed25519-sha256; t=1790174657; l=2646; i=norbert@doyensec.com; s=20260913; h=from:subject:message-id; bh=cfYNjNX25gHhCbVjC9M+4NI38O7i/5dxSGK9KDS3KKw=; b=0RklZrJRnMkEocD5BNy4CQohSSJnFN+1Xpy84302tD7CFu9c+DFUdofFA+2o4VuzZQk8ipS3v ftUDGOQBWa9DDfRDWApGP3CxkTcye1f7BkC8JIGAj7CGxcN2zNWNfxh X-Developer-Key: i=norbert@doyensec.com; a=ed25519; pk=c6ZqJ+mhvi5FloJOiMJUcIPPjT7tczbglx5gruwpVi8= X-Endpoint-Received: by B4 Relay for norbert@doyensec.com/20260913 with auth_id=1029 X-Original-From: Norbert Szetei Reply-To: norbert@doyensec.com From: 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 Ask lookup_mr() for IB_ACCESS_ON_DEMAND in both the synchronous and the asynchronous prefetch arm. mr->access carries that flag only for an MR registered as ODP, so the existing (access & mr->access) !=3D access test rejects a plain MR and the prefetch fails with -EINVAL. Fixes: 3576b0df1588 ("RDMA/rxe: Implement synchronous prefetch for ODP MRs") Cc: stable@vger.kernel.org Signed-off-by: Norbert Szetei Reviewed-by: Zhu Yanjun --- drivers/infiniband/sw/rxe/rxe_odp.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/infiniband/sw/rxe/rxe_odp.c b/drivers/infiniband/sw/rx= e/rxe_odp.c index e870efa7a0a3..f8ffd6a3219a 100644 --- a/drivers/infiniband/sw/rxe/rxe_odp.c +++ b/drivers/infiniband/sw/rxe/rxe_odp.c @@ -463,7 +463,7 @@ static int rxe_ib_prefetch_sg_list(struct ib_pd *ibpd, struct rxe_mr *mr; struct ib_umem_odp *umem_odp; =20 - mr =3D lookup_mr(pd, IB_ACCESS_LOCAL_WRITE, + mr =3D lookup_mr(pd, IB_ACCESS_LOCAL_WRITE | IB_ACCESS_ON_DEMAND, sg_list[i].lkey, RXE_LOOKUP_LOCAL); =20 if (!mr) { @@ -529,7 +529,7 @@ static int rxe_ib_advise_mr_prefetch(struct ib_pd *ibpd, =20 for (i =3D 0; i < num_sge; ++i) { /* Takes a reference, which will be released in the queued work */ - mr =3D lookup_mr(pd, IB_ACCESS_LOCAL_WRITE, + mr =3D lookup_mr(pd, IB_ACCESS_LOCAL_WRITE | IB_ACCESS_ON_DEMAND, sg_list[i].lkey, RXE_LOOKUP_LOCAL); if (!mr) { mr =3D ERR_PTR(-EINVAL); --=20 2.55.0