linux-ext4 - Re: [PATCH 1/3] ext4: report error if things go wrong when do checksum

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130105195054.GL20106@blackbox.djwong.org>
Date:	Sat, 5 Jan 2013 11:50:54 -0800
From:	"Darrick J. Wong" <darrick.wong@...cle.com>
To:	Guo Chao <yan@...ux.vnet.ibm.com>
Cc:	tytso@....edu, linux-ext4@...r.kernel.org
Subject: Re: [PATCH 1/3] ext4: report error if things go wrong when do
 checksum

On Sat, Jan 05, 2013 at 03:42:59PM +0800, Guo Chao wrote:
> In ext4_dx_csum_verify(), if we detect corrupted data,
> we do not compare checksum because checksum itself may
> be wrong, but we should report error in this case.
> 
> Cc: Darrick J. Wong <darrick.wong@...cle.com>
> Signed-off-by: Guo Chao <yan@...ux.vnet.ibm.com>
> ---
>  fs/ext4/namei.c |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c
> index cac4482..843e29f 100644
> --- a/fs/ext4/namei.c
> +++ b/fs/ext4/namei.c
> @@ -370,14 +370,14 @@ static int ext4_dx_csum_verify(struct inode *inode,
>  	c = get_dx_countlimit(inode, dirent, &count_offset);
>  	if (!c) {
>  		EXT4_ERROR_INODE(inode, "dir seems corrupt?  Run e2fsck -D.");
> -		return 1;
> +		return 0;
>  	}
>  	limit = le16_to_cpu(c->limit);
>  	count = le16_to_cpu(c->count);
>  	if (count_offset + (limit * sizeof(struct dx_entry)) >
>  	    EXT4_BLOCK_SIZE(inode->i_sb) - sizeof(struct dx_tail)) {
>  		warn_no_space_for_csum(inode);
> -		return 1;
> +		return 0;

In both of these cases we cannot figure out where the dx block checksum lives,
and therefore we have no stored checksum to compare against.  This can result
from enabling checksums on a existing filesystem and ignoring tune2fs' request
to run fsck -D to rebuild dx blocks that are completely full.  However, since
we haven't a checksum that we could use to decide if there's real corruption,
there's no cause to return -EIO to the user.  Therefore, we print a warning and
trust the sanity checks to catch totally bogus blocks, which is the best we can
hope for.

Sorry, but this doesn't seem necessary.

--D
>  	}
>  	t = (struct dx_tail *)(((struct dx_entry *)c) + limit);
>  
> -- 
> 1.7.9.5
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html