From: Tom Tucker <tom@opengridcomputing.com>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: linux-nfs@vger.kernel.org
Subject: Re: [PATCH 01/05] svcrdma: Verify read-list fits within RPCSVC_MAXPAGES
Date: Mon, 19 May 2008 20:07:52 -0500 [thread overview]
Message-ID: <1211245672.31725.111.camel@trinity.ogc.int> (raw)
In-Reply-To: <20080519182003.GC11993@fieldses.org>
On Mon, 2008-05-19 at 14:20 -0400, J. Bruce Fields wrote:
> On Sun, May 18, 2008 at 07:13:17PM -0500, Tom Tucker wrote:
> > A RDMA read-list cannot contain more elements than RPCSVC_MAXPAGES or
> > it will overflow the DTO context. Verify this when processing the
> > protocol header.
> >
> > Signed-off-by: Tom Tucker <tom@opengridcomputing.com>
> >
> > ---
> > net/sunrpc/xprtrdma/svc_rdma_recvfrom.c | 2 ++
> > 1 files changed, 2 insertions(+), 0 deletions(-)
> >
> > diff --git a/net/sunrpc/xprtrdma/svc_rdma_recvfrom.c b/net/sunrpc/xprtrdma/svc_rdma_recvfrom.c
> > index 6b16d8c..06ab484 100644
> > --- a/net/sunrpc/xprtrdma/svc_rdma_recvfrom.c
> > +++ b/net/sunrpc/xprtrdma/svc_rdma_recvfrom.c
> > @@ -306,6 +306,8 @@ static int rdma_read_xdr(struct svcxprt_rdma *xprt,
> > ch_sge_ary = (struct chunk_sge *)tmp_ch_ctxt->sge;
> >
> > svc_rdma_rcl_chunk_counts(ch, &ch_count, &byte_count);
> > + if (ch_count > RPCSVC_MAXPAGES)
> > + return -EINVAL;
> > sge_count = rdma_rcl_to_sge(xprt, rqstp, hdr_ctxt, rmsgp,
> > sge, ch_sge_ary,
> > ch_count, byte_count);
>
> If the ch_count is just the total number of bytes to be read into this
> request, then don't we also need to know at what offset they're going to
> be inserted? (Shouldn't there be some check like ch->rc_position +
> ch_count > RPCSVC_MAXPAGES ?)
>
The ch_count is the number of RPCRDMA chunk elements in the read-list.
It's not a byte count, but a scatter-gather-list length.
I think the local read-list buffer limits should be clamped by
svc_rdma_rcl_chunk_counts, however, see below...
> Also, do we verify somewhere (before calling
> svc_rdma_rcl_chunk_counts()) that rc_discrim is set on the last chunk?
>
No we don't and a Byzantine client could crash us. The computed
byte_count should also be clamped here. I'll add this to the list --
nice catch.
This kind of check along with a bunch of others should go in
svc_rdma_xdr_decode_req. I have these things planned for the 2.6.27
time-frame (along with Fast NSMR support).
Do you think it's more urgent?
Tom
> --b.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2008-05-20 1:04 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <12111560011694-git-send-email-tom@opengridcomputing.com>
[not found] ` <12111560022506-git-send-email-tom@opengridcomputing.com>
2008-05-19 18:20 ` [PATCH 01/05] svcrdma: Verify read-list fits within RPCSVC_MAXPAGES J. Bruce Fields
2008-05-20 1:07 ` Tom Tucker [this message]
[not found] ` <1211245672.31725.111.camel-SMNkleLxa3ZimH42XvhXlA@public.gmane.org>
2008-05-20 13:27 ` Talpey, Thomas
[not found] ` <RTPCLUEXC1-PRDh133t00000127-rtwIt2gI0FxT+ZUat5FNkAK/GNPrWCqfQQ4Iyu8u01E@public.gmane.org>
2008-05-20 13:56 ` J. Bruce Fields
2008-05-20 14:14 ` Talpey, Thomas
[not found] ` <1211156002624-git-send-email-tom@opengridcomputing.com>
[not found] ` <12111560022695-git-send-email-tom@opengridcomputing.com>
[not found] ` <12111560022073-git-send-email-tom@opengridcomputing.com>
[not found] ` <12111560023250-git-send-email-tom@opengridcomputing.com>
2008-05-19 19:18 ` [PATCH 05/05] svcrdma: Add dma map count and WARN_ON J. Bruce Fields
2008-05-19 19:27 ` Tom Tucker
2008-05-21 0:46 ` [PATCH 02/05] svcrdma: Refactor RDMA_WRITE dma mapping logic J. Bruce Fields
2008-05-21 2:52 ` J. Bruce Fields
2008-05-21 10:33 ` Tom Tucker
2008-05-25 19:05 ` J. Bruce Fields
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=1211245672.31725.111.camel@trinity.ogc.int \
--to=tom@opengridcomputing.com \
--cc=bfields@fieldses.org \
--cc=linux-nfs@vger.kernel.org \
/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