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
next prev parent 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.