From: Jason Gunthorpe <jgg@nvidia.com>
To: Daisuke Matsuda <matsuda-daisuke@fujitsu.com>
Cc: linux-rdma@vger.kernel.org, leonro@nvidia.com,
zyjzyj2000@gmail.com, lizhijian@fujitsu.com,
rpearsonhpe@gmail.com
Subject: Re: [PATCH] Revert "RDMA/rxe: Remove unnecessary mr testing"
Date: Wed, 7 Dec 2022 19:43:40 -0400 [thread overview]
Message-ID: <Y5ElLH2Lyw0466fK@nvidia.com> (raw)
In-Reply-To: <20221202110157.3221952-1-matsuda-daisuke@fujitsu.com>
On Fri, Dec 02, 2022 at 08:01:57PM +0900, Daisuke Matsuda wrote:
> The commit 686d348476ee ("RDMA/rxe: Remove unnecessary mr testing") causes
> a kernel crash. If responder get a zero-byte RDMA Read request, qp->resp.mr
> is not set in check_rkey(). The mr is NULL in this case, and a NULL pointer
> dereference occurs as shown below.
I don't think this is right.
What justification is there for not validating the rkey in check_rkey
just because the length is 0?
IBA 9.3.3.2 says:
A responder that supports RDMA and / or ATOMIC Operations shall verify
the R_Key, the associated access rights, and the specified virtual ad-
dress. The responder must also perform bounds checking (i.e. verify that
the length of the data being referenced does not cross the associated
memory start and end addresses). Any violation must result in the packet
being discarded and for reliable services, the generation of a NAK.
Which I do not think allows this behavior.
If check_rkey validates the rkey then this function can assume it is
not NULL in all cases, like I think it is supposed to.
Jason
next prev parent reply other threads:[~2022-12-07 23:43 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-02 11:01 [PATCH] Revert "RDMA/rxe: Remove unnecessary mr testing" Daisuke Matsuda
2022-12-02 11:45 ` Zhu Yanjun
2022-12-02 14:35 ` lizhijian
2022-12-02 14:43 ` Jason Gunthorpe
2022-12-05 5:19 ` Daisuke Matsuda (Fujitsu)
2022-12-07 23:43 ` Jason Gunthorpe [this message]
2022-12-08 6:08 ` Daisuke Matsuda (Fujitsu)
2022-12-08 12:23 ` Jason Gunthorpe
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=Y5ElLH2Lyw0466fK@nvidia.com \
--to=jgg@nvidia.com \
--cc=leonro@nvidia.com \
--cc=linux-rdma@vger.kernel.org \
--cc=lizhijian@fujitsu.com \
--cc=matsuda-daisuke@fujitsu.com \
--cc=rpearsonhpe@gmail.com \
--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.