From: Chuck Lever <chuck.lever@oracle.com>
Subject: Re: [PATCH 08/27] SUNRPC: Prevent length underflow
	in	read_flush()
Date: Mon, 29 Oct 2007 11:30:25 -0400
Message-ID: <4725FC91.4080705@oracle.com>
References: <20071026173120.31475.76007.stgit@manray.1015granger.net>
	<20071026184923.GI13033@fieldses.org>
Reply-To: chuck.lever@oracle.com
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="------------010104070503030502010806"
Cc: nfs@lists.sourceforge.net, trond.myklebust@fys.uio.no
To: "J. Bruce Fields" <bfields@fieldses.org>
In-Reply-To: <20071026184923.GI13033@fieldses.org>
Sender: nfs-bounces@lists.sourceforge.net
Errors-To: nfs-bounces@lists.sourceforge.net

This is a multi-part message in MIME format.
--------------010104070503030502010806
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

J. Bruce Fields wrote:
> On Fri, Oct 26, 2007 at 01:31:20PM -0400, Chuck Lever wrote:
>> Make sure we compare an unsigned length to an unsigned count in
>> read_flush().
> 
> OK by me, thanks.  This motivated by the hope of being able to turn on
> more compile warnings some day?

The long-term goal is cleaner, less buggy code overall.  One tactic to 
reach this goal is enabling the use of automated code checking tools.

>> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
>> ---
>>
>>  net/sunrpc/cache.c |   10 +++++-----
>>  1 files changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/net/sunrpc/cache.c b/net/sunrpc/cache.c
>> index 8e05557..578084f 100644
>> --- a/net/sunrpc/cache.c
>> +++ b/net/sunrpc/cache.c
>> @@ -1242,18 +1242,18 @@ static ssize_t read_flush(struct file *file, char __user *buf,
>>  	struct cache_detail *cd = PDE(file->f_path.dentry->d_inode)->data;
>>  	char tbuf[20];
>>  	unsigned long p = *ppos;
>> -	int len;
>> +	size_t len;
>>  
>>  	sprintf(tbuf, "%lu\n", cd->flush_time);
>>  	len = strlen(tbuf);
>>  	if (p >= len)
>>  		return 0;
>>  	len -= p;
>> -	if (len > count) len = count;
>> +	if (len > count)
>> +		len = count;
>>  	if (copy_to_user(buf, (void*)(tbuf+p), len))
>> -		len = -EFAULT;
>> -	else
>> -		*ppos += len;
>> +		return -EFAULT;
>> +	*ppos += len;
>>  	return len;
>>  }
>>  
>>
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems?  Stop.
>> Now Search log events and configuration files using AJAX and a browser.
>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>> _______________________________________________
>> NFS maillist  -  NFS@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/nfs

--------------010104070503030502010806
Content-Type: text/x-vcard; charset=utf-8;
 name="chuck.lever.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="chuck.lever.vcf"

begin:vcard
fn:Chuck Lever
n:Lever;Chuck
org:Oracle Corporation;Corporate Architecture: Linux Projects Group
adr:;;1015 Granger Avenue;Ann Arbor;MI;48104;USA
title:Principal Member of Staff
tel;work:+1 248 614 5091
x-mozilla-html:FALSE
version:2.1
end:vcard


--------------010104070503030502010806
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
--------------010104070503030502010806
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

--------------010104070503030502010806--