| 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
| ||
|
Message-Id: <889B6B31-A1F0-438D-B782-DBB855912854@sandeen.net> Date: Mon, 7 Jun 2010 20:10:03 -0500 From: Eric Sandeen <sandeen@...deen.net> To: Jeffrey Merkey <jeffmerkey@...il.com> Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org> Subject: Re: EXT3 File System Corruption 2.6.34 On Jun 7, 2010, at 6:55 PM, Jeffrey Merkey <jeffmerkey@...il.com> wrote: > ---------- 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. Here you are mistaken. Mount with data=ordered and see. Writeback can expose stale data. -Eric > 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/ > -- 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/
Powered by blists - more mailing lists