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  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 2 Nov 2017 08:44:00 -0400
From:   Brian Foster <bfoster@...hat.com>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     "Darrick J. Wong" <darrick.wong@...cle.com>,
        linux-xfs@...r.kernel.org, Dave Chinner <dchinner@...hat.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] xfs: scrub: avoid uninitialized return code

On Thu, Nov 02, 2017 at 12:11:12PM +0100, Arnd Bergmann wrote:
> The newly added xfs_scrub_da_btree_block() function has one code path
> that returns the 'error' variable without initializing it first, as
> shown by this compiler warning:
> 
> fs/xfs/scrub/dabtree.c: In function 'xfs_scrub_da_btree_block':
> fs/xfs/scrub/dabtree.c:462:9: error: 'error' may be used uninitialized in this function [-Werror=maybe-uninitialized]
> 
> Returning -EINVAL might be an appropriate return code in this case.
> 
> Fixes: 7c4a07a424c1 ("xfs: scrub directory/attribute btrees")
> Signed-off-by: Arnd Bergmann <arnd@...db.de>
> ---
>  fs/xfs/scrub/dabtree.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/xfs/scrub/dabtree.c b/fs/xfs/scrub/dabtree.c
> index 4a93cf1753d3..971566388c9a 100644
> --- a/fs/xfs/scrub/dabtree.c
> +++ b/fs/xfs/scrub/dabtree.c
> @@ -349,8 +349,10 @@ xfs_scrub_da_btree_block(
>  
>  	/* Check the pointer. */
>  	blk->blkno = blkno;
> -	if (!xfs_scrub_da_btree_ptr_ok(ds, level, blkno))
> +	if (!xfs_scrub_da_btree_ptr_ok(ds, level, blkno)) {
> +		error = -EINVAL;
>  		goto out_nobuf;
> +	}

Hmm.. is an error really the right thing to do here vs. setting the
context corrupt and returning 0? (Darrick..?) If the latter, perhaps
error should just be initialized to 0.

Brian

>  
>  	/* Read the buffer. */
>  	error = xfs_da_read_buf(dargs->trans, dargs->dp, blk->blkno, -2,
> -- 
> 2.9.0
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists