linux-kernel - Re: ext4_xattr_ibody_find:2180: inode #2669312: comm systemd-journal: corrupted in-inode xattr

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: <YO8lMpNOUsLjBqIG@mit.edu>
Date:   Wed, 14 Jul 2021 13:56:02 -0400
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     Peter Geis <pgwipeout@...il.com>
Cc:     Jan Kara <jack@...e.cz>, adilger.kernel@...ger.ca,
        linux-ext4@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: ext4_xattr_ibody_find:2180: inode #2669312: comm
 systemd-journal: corrupted in-inode xattr

On Tue, Jul 13, 2021 at 04:52:11PM -0400, Peter Geis wrote:
> > This seems to have fallen through the cracks. Have you managed to fix your
> > filesystem? If not, please obtain filesystem image using e2image (it will
> > contain only fs metadata, not any data), compress it and put it somewhere for
> > download so that we can better diagnose the issue. Thanks!
> 
> Unfortunately no I don't have the file system anymore.
> I put about two weeks into trying to fix it, but in the end I had to
> nuke it from orbit.

Sorry we didn't get back to you right away.  As Jan said, if this
happens again, it would be really helpful to use e2image.  There is a
discussion about this in the e2fsck man page, in the "REPORTING BUGS"
section.

In this specific case where there was an inode with a corrupted
extended attribute stored in the inode, you can use debugfs to print
out the inode data structure:

debugfs:  inode_dump testfile
0000  a481 0000 0000 0000 cf23 ef60 d523 ef60  .........#.`.#.`
0020  cf23 ef60 0000 0000 0000 0100 0000 0000  .#.`............
0040  0000 0800 0100 0000 0af3 0000 0400 0000  ................
0060  0000 0000 0000 0000 0000 0000 0000 0000  ................
*
0140  0000 0000 6867 c27f 0000 0000 0000 0000  ....hg..........
0160  0000 0000 0000 0000 0000 0000 9fbc 0000  ................
0200  2000 e8f9 34cc 39ec fcaf ee61 fcaf ee61   ...4.9....a...a
0220  cf23 ef60 fcaf ee61 0000 0000 0000 0000  .#.`...a........
0240  0000 02ea 0401 5400 0000 0000 0600 0000  ......T.........
0260  0000 0000 7465 7374 0000 0000 0000 0000  ....test........
0300  0000 0000 0000 0000 0000 0000 0000 0000  ................
*
0360  0000 0000 0000 0000 7473 7476 616c 0000  ........tstval..

debugfs:  inode_dump -x testfile
magic = ea020000, length = 96, value_start =4 

offset = 4 (0004), name_len = 4, name_index = 1
value_offset = 84 (0130), value_inum = 0, value_size = 6
name = test
value = tstval

last entry found at offset 24 (0030)

(And if you don't have the pathname to the file, you can also specify
the inode using the inode number in angle brackers, e.g., "inode_dump <12>")

Hopefully this won't happen to you again, but if it does, please do
let us know.

Cheers,

						- Ted