linux-kernel - Fwd: EXT3 File System Corruption 2.6.34

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-next>] [day] [month] [year] [list]

Message-ID: <AANLkTil4FMnGl7llR4N0PkXuNyEClQmTspNK6PT62PAi@mail.gmail.com>
Date:	Mon, 7 Jun 2010 17:55:22 -0600
From:	Jeffrey Merkey <jeffmerkey@...il.com>
To:	linux-kernel@...r.kernel.org
Subject: Fwd: EXT3 File System Corruption 2.6.34

---------- Forwarded message ----------
From: Jeffrey Merkey <jeffmerkey@...il.com>
Date: Mon, Jun 7, 2010 at 5:54 PM
Subject: Re: EXT3 File System Corruption 2.6.34
To: Eric Sandeen <sandeen@...deen.net>


REPLY TO ALL

CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set

Whether set this way or not, should not see corruption.  I am seeing
data corruption including the following:

/boot/grub/grub.conf getting filled with binary chars
/root/.viminfo filled with strange text chars (not binary)
.o files filled with the same garbage.

Looks like EXT3 meta data -- maybe some blocks getting transposed somewhere?

I will recreate the data patterns I see during corruption and post
here.  They are consitent with some sort of fill pattern -- at least
what I see in
viminfo is.

In the case of corrupted .o files, the endian headers are missing and
trashed in the OBJ section headers -- chances are the same kind of
garbage.

Jeff


>> Still seeing file system corruption after journal recovery in EXT3.
>> It's easy to reproduce, though the symptoms vary.  One way is to
>> rebuild a program and while the program is being compiled just shut
>> off power to the system by pulling the plug.  I am seeing the
>> /root/.viminfo file trashed after recovery if Vim was active during
>> poweroff.  I am also seeing object modules getting built which the LD
>> linker claims are "invalid" following a recovery event.  I suspect a
>> bug in the buffer cache since deleting the file still causes the old
>> data to be returned from buffer cache even when the sectors are
>> overwritten, but both are interrelated.  Seems in some way related to
>> EXT3 recovery which results in the buffer cache returning old sectors
>> and junk.
>>
>> Not hard to reproduce, but the symptoms are always a little different
>> but the /root/.viminfo file getting nuked seems a common affect of
>> this bug.
>
> "file system corruption" usually means corrupted metadata, but I guess
> here you mean file corruption, i.e. corrupted data.
>
> If you have buffered data in the cache, it will be lost when you pull
> the plug.  If your userspace doesn't sync it, this is expected.  But it's
> not clear to me what you're seeing.
>
> I'm also not clear on what you mean about deleting the file and having old
> data returned.  Maybe a little cut and paste from the screen would help
> explain what you see.
>
> I'd also check CONFIG_EXT3_DEFAULTS_TO_ORDERED and be sure you're
> using data=ordered mode by default.
>
> -Eric
>
>> Jeff
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/