linux-ext4 - Re: kernel BUG at fs/ext4/inline.c:1943!

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: <B36E2BBE-D64C-4E91-BB74-5729CE29BB03@dilger.ca>
Date:   Fri, 20 Jan 2017 12:17:34 -0700
From:   Andreas Dilger <adilger@...ger.ca>
To:     Damien Guibouret <damien.guibouret@...tition-saving.com>
Cc:     Theodore Ts'o <tytso@....edu>,
        George Spelvin <linux@...encehorizons.net>,
        linux-ext4@...r.kernel.org
Subject: Re: kernel BUG at fs/ext4/inline.c:1943!

On Jan 20, 2017, at 12:14 PM, Damien Guibouret <damien.guibouret@...tition-saving.com> wrote:
> Theodore Ts'o wrote:
>> On Wed, Jan 18, 2017 at 03:21:28AM -0500, George Spelvin wrote:
>>> I was trying to rmdir an empty directory in lost+found that accumulated
>>> during my recent problems.
>>> 
>>> EXT4-fs (md3): mounted filesystem with writeback data mode. Opts: data=writeback,delalloc
>>> 
>>> $ cd /mountpoint/lost+found
>>> $ rmdir \#1625089/
>>> 
>>> ------------[ cut here ]------------
>>> kernel BUG at fs/ext4/inline.c:1943!
>>> debugfs:  stat <1625089>
>>> Inode: 1625089   Type: directory    Mode:  0775   Flags: 0x10000000
>>> Generation: 927350643    Version: 0x00000000:00000004
>>> User:  1000   Group:   161   Project:     0   Size: 132
>>> File ACL: 1664090185    Directory ACL: 0
>>> Links: 0   Blockcount: 8
>>> Fragment:  Address: 0    Number: 0    Size: 0
>>> ctime: 0x587f2034:472c74ec -- Wed Jan 18 02:58:44 2017
>>> atime: 0x56b9e2f8:b68a7658 -- Tue Feb  9 08:00:40 2016
>>> mtime: 0x56c1bc4b:a7765de8 -- Mon Feb 15 06:53:47 2016
>>> crtime: 0x56ba9eb4:a51d90ac -- Tue Feb  9 21:21:40 2016
>>> Size of extra inode fields: 32
>>> Extended attributes:
>>> system.data (72)
>>> Inode checksum: 0xe2f12fc5
>>> Size of inline data: 132
>> OK, so the problem seems the inode in question has the INLINE_DATA
>> flag set, but i_blocks is non-zero.  And it looks like the data was
>> actually stored in an exernal data block, and the in-line xattr wasn't
>> present.
>> e2fsck should be checking and complaining if this is the case.  If
>> not, it's a bug in e2fsck.
>> And the kernel certainy shouldn't be BUG'ing when it comes across
>> what is clearly a case of file system corruption.
>> Cheers,
>> 					- Ted
>> --
>> 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
> Hello,
> 
> Perhaps I am wrong, but as the inode has a file ACL, the blockcount should be
> different from 0?  So it seems valid on this point. Or is there something that
> prevent inlined file to have ACL?

The "File ACL" label is misleading.  ACLs are stored as xattrs, (along with other
xattrs like SELinux labels), and also inline data.  However, unless the ACL is
very large it would also be stored inside the inode itself.  If there isn't space
inside the inode to store both the inline data and other xattrs, the inline data
should be bumped to an external block first (i.e. stored as a regular file),
since there is no benefit to doing the reverse.


Cheers, Andreas






Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)