linux-kernel - Re: [PATCH] befs: return BEFS_ERR if validation of ag

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:	Tue, 16 Aug 2016 08:53:03 +0100
From:	Salah Triki <salah.triki@...il.com>
To:	Luis de Bethencourt <luisbg@....samsung.com>
Cc:	akpm@...ux-foundation.org, viro@...iv.linux.org.uk,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH] befs: return BEFS_ERR if validation of ag_shift fails

On Fri, Aug 12, 2016 at 12:00:34PM +0100, Luis de Bethencourt wrote:
> On 12/08/16 11:12, Salah Triki wrote:
> > ag_shift is used by blockno2iaddr() to get allocation group number
> > from block. If ag_shift is inconsistent with block_per_ag, an out of
> > bounds allocation group may occur [1]. So add return BEFS_ERR and update
> > comment and error message to reflect this change.
> > 
> > [1] https://lkml.org/lkml/2016/8/12/42
> > 
> > Signed-off-by: Salah Triki <salah.triki@...il.com>
> > ---
> >  fs/befs/super.c | 9 ++++++---
> >  1 file changed, 6 insertions(+), 3 deletions(-)
> > 
> > diff --git a/fs/befs/super.c b/fs/befs/super.c
> > index 7c50025..2e3a3fd 100644
> > --- a/fs/befs/super.c
> > +++ b/fs/befs/super.c
> > @@ -101,10 +101,13 @@ befs_check_sb(struct super_block *sb)
> >  
> >  
> >  	/* ag_shift also encodes the same information as blocks_per_ag in a
> > -	 * different way, non-fatal consistency check
> > +	 * different way as a consistency check.
> >  	 */
> > -	if ((1 << befs_sb->ag_shift) != befs_sb->blocks_per_ag)
> > -		befs_error(sb, "ag_shift disagrees with blocks_per_ag.");
> > +	if ((1 << befs_sb->ag_shift) != befs_sb->blocks_per_ag) {
> > +		befs_error(sb, "ag_shift disagrees with blocks_per_ag. "
> > +			   "Corruption likely.");
> > +		return BEFS_ERR;
> > +	}
> >  
> >  	if (befs_sb->log_start != befs_sb->log_end ||
> >  	    befs_sb->flags == BEFS_DIRTY) {
> > 
> 
> Hi Salah,
> 
> I initially also added the BEFS_ERR return for this check. I understand
> it makes sense.
> 
> But as I mentioned in the patch adding this warning [0], a correct
> blocks_per_ag isn't mandatory. I noticed this because BeFS images
> created by Haiku OS just set blocks_per_ag to 1. Which is clearly not
> what it should be.
> 
> The file systems created by Haiku OS can be read without issues since
> sb->blocks_per_ag isn't actually used in lookups/reading file datastreams.
> 
> This is what I get in dmesg when loading a Haiku OS image with
> CONFIG_BEFS_DEBUG on:
> ...
> [  196.376651] befs: (loop1):   blocks_per_ag 1
> [  196.376652] befs: (loop1):   ag_shift 14
> ...
> 
> With ag_shift of 14, blocks_per_ag should be 16,384.
> 
> If we return BEFS_ERR, the system will refuse to mount and users won't be
> able to read these Haiku OS images they could read before. Unfortunate that
> Haiku OS is not using blocks_per_ag properly, but users and avoiding
> regressions go first.
> 
> Which BeFS images are you using to test the befs code? Since all the ones
> I have are generated from Haiku OS, all of them have a bad blocks_per_ag.
> LOL
> 
> Maybe we should contact Haiku OS developers and ask them to write a correct
> blocks_per_ag. Though we should also support images created before they fix
> this.
> 
> Sorry you spent time on this when the issue is out of our control :(
> Nacked-by: Luis de Bethencourt <luisbg@....samsung.com>
> 
> Thanks,
> Luis
> 
> [0] https://lkml.org/lkml/2016/8/9/816

Hi Luis,

>  but users and avoiding regressions go first.

Indeed, you are right to stress the importance of users and avoiding
regressions.

> Which BeFS images are you using to test the befs code? 

http://befs-driver.sourceforge.net/

> Maybe we should contact Haiku OS developers and ask them to write a correct
> blocks_per_ag. 

Yes, it is a good idea.

Thanks,
Salah