All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Tom Tucker <tom@opengridcomputing.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>, Tom Tucker <tom@ogc.us>,
	"J. Bruce Fields" <bfields@redhat.com>,
	netdev@vger.kernel.org, linux-nfs@vger.kernel.org
Subject: Re: question about map_read_chunks()
Date: Fri, 27 Sep 2013 16:15:19 -0400	[thread overview]
Message-ID: <20130927201519.GC22640@fieldses.org> (raw)
In-Reply-To: <5245A2DE.9020307@opengridcomputing.com>

On Fri, Sep 27, 2013 at 10:23:10AM -0500, Tom Tucker wrote:
> Hi Dan,
> 
> On 9/27/13 7:21 AM, Dan Carpenter wrote:
> >I have looked at this again, and I still worry that it looks like a bug.
> >(remote security related blah blah blah).
> >
> >regards,
> >dan carpenter
> >
> >On Mon, Feb 20, 2012 at 12:50:19PM +0300, Dan Carpenter wrote:
> >>I had a couple questions about some map_read_chunks().
> >>
> >>net/sunrpc/xprtrdma/svc_rdma_recvfrom.c
> >>
> >>    150          ch_bytes = ntohl(ch->rc_target.rs_length);
> >>                 ^^^^^^^^
> >>It look like this is 32 bits from the network?
> >>
> >>    151          head->arg.head[0] = rqstp->rq_arg.head[0];
> >>    152          head->arg.tail[0] = rqstp->rq_arg.tail[0];
> >>    153          head->arg.pages = &head->pages[head->count];
> >>    154          head->hdr_count = head->count; /* save count of hdr pages */
> >>    155          head->arg.page_base = 0;
> >>    156          head->arg.page_len = ch_bytes;
> >>    157          head->arg.len = rqstp->rq_arg.len + ch_bytes;
> >>                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >>Can overflow.
> >>    158          head->arg.buflen = rqstp->rq_arg.buflen + ch_bytes;
> agreed.
> >>                                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >>Same.  I didn't follow it through to see if an overflow matters.  Does
> >>it?
> >>
> >>    159          head->count++;
> >>    160          chl_map->ch[0].start = 0;
> >>    161          while (byte_count) {
> >>    162                  rpl_map->sge[sge_no].iov_base =
> >>    163                          page_address(rqstp->rq_arg.pages[page_no]) + page_off;
> >>    164                  sge_bytes = min_t(int, PAGE_SIZE-page_off, ch_bytes);
> >>                                           ^^^
> >>This is the wrong cast to use.  A large ch_bytes would be counted as a
> >>negative value and get around the cap here.
> True, but if we validate the wire data like we should, that's
> probably not an issue.

Well, my last attempt to do rdma nfs io resulted in an instant server
reboot, so I can take a look at this but it may be the least of our
problems....

--b.

WARNING: multiple messages have this Message-ID (diff)
From: "J. Bruce Fields" <bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
To: Tom Tucker <tom-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
Cc: Dan Carpenter
	<dan.carpenter-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>,
	Tom Tucker <tom-/Yg/VP3ZvrM@public.gmane.org>,
	"J. Bruce Fields"
	<bfields-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: question about map_read_chunks()
Date: Fri, 27 Sep 2013 16:15:19 -0400	[thread overview]
Message-ID: <20130927201519.GC22640@fieldses.org> (raw)
In-Reply-To: <5245A2DE.9020307-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>

On Fri, Sep 27, 2013 at 10:23:10AM -0500, Tom Tucker wrote:
> Hi Dan,
> 
> On 9/27/13 7:21 AM, Dan Carpenter wrote:
> >I have looked at this again, and I still worry that it looks like a bug.
> >(remote security related blah blah blah).
> >
> >regards,
> >dan carpenter
> >
> >On Mon, Feb 20, 2012 at 12:50:19PM +0300, Dan Carpenter wrote:
> >>I had a couple questions about some map_read_chunks().
> >>
> >>net/sunrpc/xprtrdma/svc_rdma_recvfrom.c
> >>
> >>    150          ch_bytes = ntohl(ch->rc_target.rs_length);
> >>                 ^^^^^^^^
> >>It look like this is 32 bits from the network?
> >>
> >>    151          head->arg.head[0] = rqstp->rq_arg.head[0];
> >>    152          head->arg.tail[0] = rqstp->rq_arg.tail[0];
> >>    153          head->arg.pages = &head->pages[head->count];
> >>    154          head->hdr_count = head->count; /* save count of hdr pages */
> >>    155          head->arg.page_base = 0;
> >>    156          head->arg.page_len = ch_bytes;
> >>    157          head->arg.len = rqstp->rq_arg.len + ch_bytes;
> >>                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >>Can overflow.
> >>    158          head->arg.buflen = rqstp->rq_arg.buflen + ch_bytes;
> agreed.
> >>                                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >>Same.  I didn't follow it through to see if an overflow matters.  Does
> >>it?
> >>
> >>    159          head->count++;
> >>    160          chl_map->ch[0].start = 0;
> >>    161          while (byte_count) {
> >>    162                  rpl_map->sge[sge_no].iov_base =
> >>    163                          page_address(rqstp->rq_arg.pages[page_no]) + page_off;
> >>    164                  sge_bytes = min_t(int, PAGE_SIZE-page_off, ch_bytes);
> >>                                           ^^^
> >>This is the wrong cast to use.  A large ch_bytes would be counted as a
> >>negative value and get around the cap here.
> True, but if we validate the wire data like we should, that's
> probably not an issue.

Well, my last attempt to do rdma nfs io resulted in an instant server
reboot, so I can take a look at this but it may be the least of our
problems....

--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2013-09-27 20:15 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-20  9:50 question about map_read_chunks() Dan Carpenter
2012-02-20  9:50 ` Dan Carpenter
2013-09-27 12:21 ` Dan Carpenter
2013-09-27 15:23   ` Tom Tucker
2013-09-27 15:23     ` Tom Tucker
2013-09-27 20:15     ` J. Bruce Fields [this message]
2013-09-27 20:15       ` J. Bruce Fields
     [not found] <20120220182003.GL2912@mwanda>
2012-02-20 18:44 ` Tom Tucker

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=20130927201519.GC22640@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=bfields@redhat.com \
    --cc=dan.carpenter@oracle.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=tom@ogc.us \
    --cc=tom@opengridcomputing.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.