linux-ext4 - Re: Weird filesystem corruption from wayland / radeon / chromium

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: <878vajq1g6.fsf@passepartout.tim-landscheidt.de>
Date:	Fri, 02 Nov 2012 18:55:37 +0000
From:	Tim Landscheidt <tim@...-landscheidt.de>
To:	linux-ext4@...r.kernel.org
Subject: Re: Weird filesystem corruption from wayland / radeon / chromium

Eric Sandeen <sandeen@...hat.com> wrote:

> [...]
>> Shortly after starting Chrome, the messages reappeared
>> again:

>> | Nov  2 15:15:48 passepartout kernel: [ 1979.196296] EXT4-fs error (device dm-4): ext4_ext_search_left:1304: inode #274258: comm flush-253:4: ix (3666) != EXT_FIRST_INDEX (0) (depth 0)!
>> | Nov  2 15:15:48 passepartout kernel: [ 1979.196306] EXT4-fs (dm-4): delayed block allocation failed for inode 274258 at logical offset 3672 with max blocks 2 with error -5
>> | Nov  2 15:15:48 passepartout kernel: [ 1979.196308] EXT4-fs (dm-4): This should not happen!! Data will be lost
>> | Nov  2 15:15:48 passepartout kernel: [ 1979.196308]

>> And indeed:

>> | [root@...separtout ~]# find ~tim -inum 274258
>> | /home/tim/.cache/google-chrome/Default/Cache/data_3
>> | [root@...separtout ~]#

>> So somehow Chromium/Chrome seems to be able to trigger ker-
>> nel messages indicating a file system error while no actual
>> file system errors seem to occur (very big assumption here
>> because I have no idea how to detect if "data_3" is cor-
>> rupted).

> So it's the same inode every time.

> What does

> # debugfs -R "dump_extents <274258>" /dev/dm-4

> show? (or whatever the appropriate device node path is)

See attachment.

> You might also create an e2image -r fs image so we could
> take a closer look later if needed.  You could provide it offline if
> filenames are sensitive (no file data is contained in the image).
> Or you could use the filename obfuscation option.

> But creating the e2image now just to capture the state might
> be good.

> [...]

As this is my home directory and never meant to be pub-
lished :-), I have never assessed whether filenames there
are sensitive, but I don't want to take any chances and will
send you a private link to the obfuscated image per separate
mail.  I have taken a non-obfuscated image as well.

The warning is still appearing:

| Nov  2 18:23:42 passepartout kernel: [13252.909399] EXT4-fs error (device dm-4): ext4_ext_search_left:1304: inode #274258: comm flush-253:4: ix (3666) != EXT_FIRST_INDEX (0) (depth 0)!
| Nov  2 18:23:42 passepartout kernel: [13252.909411] EXT4-fs (dm-4): delayed block allocation failed for inode 274258 at logical offset 4076 with max blocks 2 with error -5
| Nov  2 18:23:42 passepartout kernel: [13252.909413] EXT4-fs (dm-4): This should not happen!! Data will be lost
| Nov  2 18:23:42 passepartout kernel: [13252.909413]

Tim

View attachment "dump_extents.txt" of type "text/plain" (19930 bytes)