linux-ext4 - Re: [PATCH] ext4: Fix kernel BUG at fs/ext4/mballoc.c:910!

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]

Date:	Wed, 13 Feb 2008 13:33:05 -0700
From:	Andreas Dilger <adilger@....com>
To:	Valerie Clement <valerie.clement@...l.net>
Cc:	linux-ext4 <linux-ext4@...r.kernel.org>,
	"cmm@...ibm.com" <cmm@...ibm.com>
Subject: Re: [PATCH] ext4: Fix kernel BUG at fs/ext4/mballoc.c:910!

On Feb 13, 2008  18:19 +0100, Valerie Clement wrote:
> From: Valerie Clement <valerie.clement@...l.net>
> 
> With the flex_bg feature enabled, a large file creation oopses the
> kernel.
> The BUG_ON is:
> 	BUG_ON(len >= EXT4_BLOCKS_PER_GROUP(sb));
>
> As the allocation of the bitmaps and the inode table can be done
> outside the block group with flex_bg, this allows to allocate up to
> EXT4_BLOCKS_PER_GROUP blocks in a group.

Caution is needed here.  In the past we were limited to BLOCKS_PER_GROUP()
blocks per extent (32768 blocks at most, regardless of blocksize I think)
but now an extent might be larger.

Can you please verify that the extent-length limits for "initialized" vs.
"uninitialized" extents are being hit so that extents don't accidentally
grow to be > 32768 blocks long and suddenly get marked as short uninitialized
extents.

Note that the assertion can still be hit if groups are created with fewer
blocks, or with blocksize < 4096.  For example, if we have blocksize = 1024
this gives BLOCKS_PER_GROUP=8192, but an extent can be up to 32768 blocks.

I think the right assertion is now:

	BUG_ON(len > EXT4_INIT_MAX_LEN);

if FLEX_BG is active.  I'm not sure if we want to keep the stricter assertion:

	BUG_ON(len > EXT4_HAS_INCOMPAT_FEATURE_FLEX_BG(sb) ? EXT4_INIT_MAX_LEN :
						EXT4_BLOCKS_PER_GROUP(sb));

but it might be worthwhile at least initially, and I don't think the CPU cost
is very high.

> diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
> index b0f84b4..0275150 100644
> --- a/fs/ext4/mballoc.c
> +++ b/fs/ext4/mballoc.c
> @@ -907,7 +907,7 @@ static void ext4_mb_mark_free_simple(struct super_block *sb,
>  	unsigned short chunk;
>  	unsigned short border;
>  
> -	BUG_ON(len >= EXT4_BLOCKS_PER_GROUP(sb));
> +	BUG_ON(len > EXT4_BLOCKS_PER_GROUP(sb));
>  
>  	border = 2 << sb->s_blocksize_bits;
>  
> @@ -3286,7 +3286,7 @@ static void ext4_mb_normalize_request(struct ext4_allocation_context *ac,
>  	}
>  	BUG_ON(start + size <= ac->ac_o_ex.fe_logical &&
>  			start > ac->ac_o_ex.fe_logical);
> -	BUG_ON(size <= 0 || size >= EXT4_BLOCKS_PER_GROUP(ac->ac_sb));
> +	BUG_ON(size <= 0 || size > EXT4_BLOCKS_PER_GROUP(ac->ac_sb));

Please separate this into two BUG_ON() statements, so it is clear which
one is being hit.

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.

-
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