From: "J. Bruce Fields" <bfields@fieldses.org>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: trond.myklebust@netapp.com, linux-nfs@vger.kernel.org
Subject: Re: [PATCH 06/24] SUNRPC: Sanity check incoming UDP datagram lengths properly
Date: Mon, 14 Apr 2008 16:54:11 -0400 [thread overview]
Message-ID: <20080414205411.GQ15950@fieldses.org> (raw)
In-Reply-To: <57F5E6FE-975E-4936-AD04-13956747A18E@oracle.com>
On Mon, Apr 14, 2008 at 03:55:16PM -0400, Chuck Lever wrote:
> On Apr 14, 2008, at 2:38 PM, J. Bruce Fields wrote:
>> On Mon, Apr 14, 2008 at 12:27:23PM -0400, Chuck Lever wrote:
>>> Clean up: ensure svc_udp_recvfrom() is getting at least a full UDP
>>> header
>>> to avoid potential negative intermediate values.
>>
>> Is it legal in this case for skb_recv_datagram() to return an skb
>> without at least that minimum length? (And if not, should this be a
>> BUG()?)
>>
>>
>>> A similar sanity check is already used in the RPC client.
>>
>> This one?:
>>
>> repsize = skb->len - sizeof(struct udphdr);
>> if (repsize < 4) {
>> dprintk("RPC: impossible RPC reply size %d!\n", repsize);
>> goto dropit;
>> }
>>
>> I assumed it was needed because of the rpc-level check (for the 4
>> bytes worth
>> of xid), not because it needed udp-level checking.
>
> The server side check programmatically guarantees we get a non-negative
> number when we compute "bytes."
Would a BUG() accomplish the same thing?
--b.
> Thus we can use an unsigned variable and
> eliminate a mixed sign comparison later on.
>
> We can add a "+ sizeof(u32)" to the check if you like.
>
>>> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
>>> ---
>>>
>>> net/sunrpc/svcsock.c | 20 +++++++++++++-------
>>> 1 files changed, 13 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/net/sunrpc/svcsock.c b/net/sunrpc/svcsock.c
>>> index d077071..de29e7f 100644
>>> --- a/net/sunrpc/svcsock.c
>>> +++ b/net/sunrpc/svcsock.c
>>> @@ -431,6 +431,7 @@ static int svc_udp_recvfrom(struct svc_rqst
>>> *rqstp)
>>> } buffer;
>>> struct cmsghdr *cmh = &buffer.hdr;
>>> int err, len;
>>> + unsigned int bytes;
>>> struct msghdr msg = {
>>> .msg_name = svc_addr(rqstp),
>>> .msg_control = cmh,
>>> @@ -484,8 +485,13 @@ static int svc_udp_recvfrom(struct svc_rqst
>>> *rqstp)
>>> */
>>> svc_xprt_received(&svsk->sk_xprt);
>>>
>>> - len = skb->len - sizeof(struct udphdr);
>>> - rqstp->rq_arg.len = len;
>>> + if (skb->len < sizeof(struct udphdr)) {
>>> + dprintk("svc: bad UDP datagram length: %u\n", skb->len);
>>> + skb_free_datagram(svsk->sk_sk, skb);
>>> + return 0;
>>> + }
>>> + bytes = skb->len - sizeof(struct udphdr);
>>> + rqstp->rq_arg.len = bytes;
>>>
>>> rqstp->rq_prot = IPPROTO_UDP;
>>>
>>> @@ -515,7 +521,7 @@ static int svc_udp_recvfrom(struct svc_rqst
>>> *rqstp)
>>> /* we can use it in-place */
>>> rqstp->rq_arg.head[0].iov_base = skb->data +
>>> sizeof(struct udphdr);
>>> - rqstp->rq_arg.head[0].iov_len = len;
>>> + rqstp->rq_arg.head[0].iov_len = bytes;
>>> if (skb_checksum_complete(skb)) {
>>> skb_free_datagram(svsk->sk_sk, skb);
>>> return 0;
>>> @@ -524,12 +530,12 @@ static int svc_udp_recvfrom(struct svc_rqst
>>> *rqstp)
>>> }
>>>
>>> rqstp->rq_arg.page_base = 0;
>>> - if (len <= rqstp->rq_arg.head[0].iov_len) {
>>> - rqstp->rq_arg.head[0].iov_len = len;
>>> + if (bytes <= rqstp->rq_arg.head[0].iov_len) {
>>> + rqstp->rq_arg.head[0].iov_len = bytes;
>>> rqstp->rq_arg.page_len = 0;
>>> rqstp->rq_respages = rqstp->rq_pages+1;
>>> } else {
>>> - rqstp->rq_arg.page_len = len - rqstp->rq_arg.head[0].iov_len;
>>> + rqstp->rq_arg.page_len = bytes - rqstp->rq_arg.head[0].iov_len;
>>> rqstp->rq_respages = rqstp->rq_pages + 1 +
>>> DIV_ROUND_UP(rqstp->rq_arg.page_len, PAGE_SIZE);
>>> }
>>> @@ -537,7 +543,7 @@ static int svc_udp_recvfrom(struct svc_rqst
>>> *rqstp)
>>> if (serv->sv_stats)
>>> serv->sv_stats->netudpcnt++;
>>>
>>> - return len;
>>> + return bytes;
>>> }
>>>
>>> static int
>>>
>
> --
> Chuck Lever
> chuck[dot]lever[at]oracle[dot]com
>
>
>
next prev parent reply other threads:[~2008-04-14 20:54 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-14 16:26 [PATCH 00/24] RPC server support rpcbind v4 plus additional clean ups Chuck Lever
[not found] ` <20080414162108.12741.73233.stgit-meopP2rzCrTwdl/1UfZZQIVfYA8g3rJ/@public.gmane.org>
2008-04-14 16:26 ` [PATCH 01/24] NFS: Use NFSDBG_FILE for all fops Chuck Lever
2008-04-14 16:26 ` [PATCH 02/24] NFS: Fix trace debugging nits in write.c Chuck Lever
2008-04-14 16:27 ` [PATCH 03/24] SUNRPC: RPC server still uses 2.4 method for disabling TCP Nagle Chuck Lever
[not found] ` <20080414162701.12741.10868.stgit-meopP2rzCrTwdl/1UfZZQIVfYA8g3rJ/@public.gmane.org>
2008-04-14 17:38 ` J. Bruce Fields
2008-04-14 16:27 ` [PATCH 04/24] SUNRPC: Address potential buffer length overflow in svc_sendto Chuck Lever
[not found] ` <20080414162708.12741.71691.stgit-meopP2rzCrTwdl/1UfZZQIVfYA8g3rJ/@public.gmane.org>
2008-04-14 17:48 ` J. Bruce Fields
2008-04-14 19:43 ` Chuck Lever
2008-04-14 20:35 ` J. Bruce Fields
2008-04-14 16:27 ` [PATCH 05/24] SUNRPC: Address potential buffer length overflow in svc_tcp_sendto Chuck Lever
2008-04-14 16:27 ` [PATCH 06/24] SUNRPC: Sanity check incoming UDP datagram lengths properly Chuck Lever
[not found] ` <20080414162723.12741.35500.stgit-meopP2rzCrTwdl/1UfZZQIVfYA8g3rJ/@public.gmane.org>
2008-04-14 18:38 ` J. Bruce Fields
2008-04-14 19:55 ` Chuck Lever
2008-04-14 20:54 ` J. Bruce Fields [this message]
2008-04-14 21:38 ` Chuck Lever
2008-04-14 16:27 ` [PATCH 07/24] SUNRPC: Update RPC server's TCP record marker decoder Chuck Lever
[not found] ` <20080414162730.12741.97124.stgit-meopP2rzCrTwdl/1UfZZQIVfYA8g3rJ/@public.gmane.org>
2008-04-14 18:49 ` J. Bruce Fields
2008-04-14 16:27 ` [PATCH 08/24] SUNRPC: Use unsigned index when looping over arrays Chuck Lever
2008-04-14 16:27 ` [PATCH 09/24] " Chuck Lever
[not found] ` <20080414162745.12741.37176.stgit-meopP2rzCrTwdl/1UfZZQIVfYA8g3rJ/@public.gmane.org>
2008-04-14 18:51 ` J. Bruce Fields
2008-04-14 16:27 ` [PATCH 10/24] SUNRPC: Use unsigned loop and array index in svc_init_buffer() Chuck Lever
[not found] ` <20080414162752.12741.15628.stgit-meopP2rzCrTwdl/1UfZZQIVfYA8g3rJ/@public.gmane.org>
2008-04-14 18:51 ` J. Bruce Fields
2008-04-14 16:28 ` [PATCH 11/24] SUNRPC: Remove obsolete messages during transport connect Chuck Lever
2008-04-14 16:28 ` [PATCH 12/24] SUNRPC: More useful debugging output for rpcb client Chuck Lever
2008-04-14 16:28 ` [PATCH 13/24] SUNRPC: Document some naked integers in rpcbind client Chuck Lever
2008-04-14 16:28 ` [PATCH 14/24] SUNRPC: Use correct XDR encoding procedure for rpcbind SET/UNSET Chuck Lever
2008-04-14 16:28 ` [PATCH 15/24] SUNRPC: Introduce a specific rpcb_create for contacting localhost Chuck Lever
2008-04-14 16:28 ` [PATCH 16/24] SUNRPC: None of rpcb_create's callers wants a privileged ephemeral port Chuck Lever
2008-04-14 16:28 ` [PATCH 17/24] SUNRPC: Refactor rpcb_register to make rpcbindv4 support easier Chuck Lever
2008-04-14 16:28 ` [PATCH 18/24] SUNRPC: introduce new task flag that fails requests on xprt disconnect Chuck Lever
2008-04-14 16:28 ` [PATCH 19/24] SUNRPC: Quickly detect missing portmapper during RPC service registration Chuck Lever
2008-04-14 16:29 ` [PATCH 20/24] SUNRPC: Support registering IPv6 interfaces with local rpcbind daemon Chuck Lever
2008-04-14 16:29 ` [PATCH 21/24] SUNRPC: Split portmap unregister API into separate function Chuck Lever
2008-04-14 16:29 ` [PATCH 22/24] SUNRPC: Use the new rpcb_v4_register() API in svc_unregister() Chuck Lever
2008-04-14 16:29 ` [PATCH 23/24] SUNRPC: Use new rpcb_v4_register() interface in svc_register() Chuck Lever
2008-04-14 16:29 ` [PATCH 24/24] SUNRPC: Add kernel build option to disable server-side use of rpcbind v3/v4 Chuck Lever
2008-04-14 19:14 ` [PATCH 00/24] RPC server support rpcbind v4 plus additional clean ups J. Bruce Fields
2008-04-14 20:05 ` Chuck Lever
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=20080414205411.GQ15950@fieldses.org \
--to=bfields@fieldses.org \
--cc=chuck.lever@oracle.com \
--cc=linux-nfs@vger.kernel.org \
--cc=trond.myklebust@netapp.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox