linux-ext4 - Re: [4.7-rc6 ext3 BUG] kernel BUG at fs/ext4/xattr.c:1331

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: <20160801121930.GB19431@quack2.suse.cz>
Date:	Mon, 1 Aug 2016 14:19:30 +0200
From:	Jan Kara <jack@...e.cz>
To:	Theodore Ts'o <tytso@....edu>
Cc:	Jan Kara <jack@...e.cz>, Dave Chinner <david@...morbit.com>,
	Eric Sandeen <sandeen@...hat.com>, linux-ext4@...r.kernel.org
Subject: Re: [4.7-rc6 ext3 BUG] kernel BUG at fs/ext4/xattr.c:1331

On Sun 31-07-16 23:09:09, Ted Tso wrote:
> On Fri, Jul 29, 2016 at 08:42:10AM +0200, Jan Kara wrote:
> > 
> > I have written some fixes, working on testing them... So hopefully I can
> > submit them later today or next week.
> 
> How complicated are the fixes?  This should work as a temporary
> workaround and it going to be very simple to backport.

Relatively simple but there are still some bugs lurking - I have the
original issue fixed but I have implemented xfstests which stress the inode
expansion code in various ways and so far they are still able to crash the
kernel... Tomorrow I will be looking more into it and hopefully will be
able to finish the fixes.

Regarding your patch - I think it's a reasonable band-aid although I'll
have to backport proper fixes to 4.4 anyway (it's a base of our next
enterprise release), which is where i_projid got introduced as well, so
eventually we will have proper stable fixes for all relevant kernels
anyway.

								Honza

> commit e92d5b1cf6af642bc5018562e58044fd771f82bf
> Author: Theodore Ts'o <tytso@....edu>
> Date:   Sun Jul 31 23:08:28 2016 -0400
> 
>     ext4: suppress inode growth for file systems w/o project quota
>     
>     We have not added a new "extra" inode field in a very long time, and
>     the code to deal with moving the extended attributes down to make room
>     for the extra inode fields has bitrotted and can cause kernel BUGS.
>     
>     Very few people will likely use project quotas (and those that do will
>     likely be creating a new file system from scratch) so as a temporary
>     pallative until we are sure the inode expansion code is all sane,
>     let's not try to expand the inode "extra" fields if the project
>     feature has not been enabled.
>     
>     Cc: stable@...r.kernel.org # v4.4+
>     Signed-off-by: Theodore Ts'o <tytso@....edu>
> 
> diff --git a/fs/ext4/super.c b/fs/ext4/super.c
> index c13a4e4..e2622ba 100644
> --- a/fs/ext4/super.c
> +++ b/fs/ext4/super.c
> @@ -3968,6 +3968,17 @@ no_journal:
>  	if (sbi->s_inode_size > EXT4_GOOD_OLD_INODE_SIZE) {
>  		sbi->s_want_extra_isize = sizeof(struct ext4_inode) -
>  						     EXT4_GOOD_OLD_INODE_SIZE;
> +		/*
> +		 * This is a temporary hack; we have not added a new
> +		 * "extra" inode field in a long time, and the code to
> +		 * expand the inode structure has bitrotted and can
> +		 * cause kernel BUG's.  If the file system does not
> +		 * have the project feature, let's not try to expand
> +		 * the inode's extra size as a temporary pallitive
> +		 * until we can fix up the inode expansion code.
> +		 */
> +		if (!ext4_has_feature_project(sb))
> +			sbi->s_want_extra_isize -= sizeof(__le32);
>  		if (ext4_has_feature_extra_isize(sb)) {
>  			if (sbi->s_want_extra_isize <
>  			    le16_to_cpu(es->s_want_extra_isize))
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR
--
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