linux-kernel - Re: [PATCH v2] hugetlb: unsigned ret cannot be negative.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <20081203003517.423f21f6.akpm@linux-foundation.org>
Date:	Wed, 3 Dec 2008 00:35:17 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Roel Kluin <roel.kluin@...il.com>
Cc:	wli@...omorphy.com, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org
Subject: Re: [PATCH v2] hugetlb: unsigned ret cannot be negative.

On Tue, 02 Dec 2008 23:51:06 +0100 Roel Kluin <roel.kluin@...il.com> wrote:

> Andrew Morton wrote:
> > On Sat, 29 Nov 2008 06:36:59 -0500
> > roel kluin <roel.kluin@...il.com> wrote:
> > 
> >> unsigned long ret cannot be negative, but ret can get -EFAULT.
> >>
> >> Signed-off-by: Roel Kluin <roel.kluin@...il.com>
> >> ---
> >> hugetlbfs_read_actor() returns int,
> >> see 
> >> vi fs/hugetlbfs/inode.c +187
> >>
> >> diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
> >> index 61edc70..0af64e4 100644
> >> --- a/fs/hugetlbfs/inode.c
> >> +++ b/fs/hugetlbfs/inode.c
> >> @@ -252,6 +252,7 @@ static ssize_t hugetlbfs_read(struct file *filp, char __user *buf,
> >>  	for (;;) {
> >>  		struct page *page;
> >>  		unsigned long nr, ret;
> >> +		int ra;
> >>  
> >>  		/* nr is the maximum number of bytes to copy from this page */
> >>  		nr = huge_page_size(h);
> >> @@ -279,15 +280,16 @@ static ssize_t hugetlbfs_read(struct file *filp, char __user *buf,
> >>  			/*
> >>  			 * We have the page, copy it to user space buffer.
> >>  			 */
> >> -			ret = hugetlbfs_read_actor(page, offset, buf, len, nr);
> >> +			ra = hugetlbfs_read_actor(page, offset, buf, len, nr);
> >>  		}
> >> -		if (ret < 0) {
> >> +		if (ra < 0) {
> 
> > `ra' can obviously be used uninitialised here.  The compiler reports
> > this, too.
> 
> Yes, it was incomplete as well, sorry. This should be OK.
> (checkpatch tested)
> --------------->8----------------8<---------------------
> unsigned long ret cannot be negative, but ret can get -EFAULT.
> 
> Signed-off-by: Roel Kluin <roel.kluin@...il.com>
> ---
> diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
> index 61edc70..07fa7e3 100644
> --- a/fs/hugetlbfs/inode.c
> +++ b/fs/hugetlbfs/inode.c
> @@ -252,6 +252,7 @@ static ssize_t hugetlbfs_read(struct file *filp, char __user *buf,
>  	for (;;) {
>  		struct page *page;
>  		unsigned long nr, ret;
> +		int ra;
>  
>  		/* nr is the maximum number of bytes to copy from this page */
>  		nr = huge_page_size(h);
> @@ -274,16 +275,19 @@ static ssize_t hugetlbfs_read(struct file *filp, char __user *buf,
>  			 */
>  			ret = len < nr ? len : nr;
>  			if (clear_user(buf, ret))
> -				ret = -EFAULT;
> +				ra = -EFAULT;
> +			else
> +				ra = 0;
>  		} else {
>  			/*
>  			 * We have the page, copy it to user space buffer.
>  			 */
> -			ret = hugetlbfs_read_actor(page, offset, buf, len, nr);
> +			ra = hugetlbfs_read_actor(page, offset, buf, len, nr);
> +			ret = ra;
>  		}
> -		if (ret < 0) {
> +		if (ra < 0) {
>  			if (retval == 0)
> -				retval = ret;
> +				retval = ra;
>  			if (page)
>  				page_cache_release(page);
>  			goto out;

Looks like it'll work, I think.

That function is pretty sad-looking now.  It has `ra', `ret' and
`retval', all rather confusingly.  After being renamed to something
useful, `ret' should have type size_t, hugetlbfs_read_actor() should
return size_t and the whole logic around these three things needs a can
of drano tipped down it.

Oh well.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/