linux-ext4 - Re: [patch 1/2 v2] ext4: simplify some code in read_mmp

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]

Date:	Mon, 17 Aug 2015 10:47:14 -0600
From:	Andreas Dilger <adilger@...ger.ca>
To:	Theodore Ts'o <tytso@....edu>
Cc:	Dan Carpenter <dan.carpenter@...cle.com>,
	Ext4 Developers List <linux-ext4@...r.kernel.org>,
	kernel-janitors@...r.kernel.org
Subject: Re: [patch 1/2 v2] ext4: simplify some code in read_mmp_block()

On Aug 15, 2015, at 9:37 AM, Theodore Ts'o <tytso@....edu> wrote:
> 
> On Fri, Aug 14, 2015 at 11:03:46AM -0600, Andreas Dilger wrote:
>>> My static check complains because we have:
>>> 
>>> 	if (!*bh)
>>> 		return -ENOMEM;
>>> 	if (*bh) {
>>> 
>>> The second check is unnecessary.
>>> 
>>> I've simplified this code by moving the "if (!*bh)" checks around.  Also Andreas Dilger says we should probably print a warning if
>>> sb_getblk() fails.
>>> 
>>> Signed-off-by: Dan Carpenter <dan.carpenter@...cle.com>
>> 
>> Reviewed-by: Andreas Dilger <adilger@...ger.ca>
> 
> Applied, thanks.  I've changed the patch slightly to also print a
> warning if the MMP magic number and/or checksum for the MMP block
> doesn't check out, and to print the error code to disambiguate between
> the various failure cases.

I agree that is an improvement.

> One thing, from looking at the function --- it looks like it might be
> a good idea if we were to move the call to clear_buffer_uptodate() to
> *after* the sb_getblk() call, no?
> 
> Otherwise we don't reread the MMP block if it is already in the cache,
> and it is the first time read_mmp_block() is called in a function in
> fs/ext4/mmp.c.....

Good catch.  Fortunately, this didn't cause dangerous MMP operation
since the MMP block is invalidated and read a second time after a
delay (to catch cases of concurrent mounts) and compared to the
original.

At worst the first (stale) read would result in the second read
causing a false mismatch and a cause an error during mount.  While
not dangerous, this could also be annoying and is good to fix.

Cheers, Andreas





--
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