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: <117B103E-8DA6-4DC7-A425-4F0108B2222C@dilger.ca>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ