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
| ||
|
Date: Tue, 8 Sep 2009 15:40:45 -0400 From: Theodore Tso <tytso@....edu> To: Curt Wohlgemuth <curtw@...gle.com> Cc: Valerie Aurora <vaurora@...hat.com>, ext4 development <linux-ext4@...r.kernel.org> Subject: Re: Odd "leak" of extent info into data blocks? On Tue, Sep 08, 2009 at 11:21:11AM -0700, Curt Wohlgemuth wrote: > Hi Valerie: > > On Tue, Sep 8, 2009 at 10:56 AM, Valerie Aurora<vaurora@...hat.com> wrote: > > Hey, did you figure this out? If not, I want to have a bug open > > somewhere. > > Yes, sorry. I was going to post a patch for this, but have been > waiting to verify that it really fixes the issue. And see the thread > started by Frank Mayhar about fsync issues as well... > > The problem is a race, between the last write to a to-be-freed > metadata block (to update the extent header) and the block being > marked free in the on-disk/buddy bitmaps. Note that this only happens > without a journal, since *with* a journal the ordering is done > correctly. Just to clarify, this a race that shows up even without an unclean shutdown, right? > Without a journal, the block buffer_head is written to, the > buffer_head is marked dirty, and the bitmaps are updated via > ext4_free_blocks(). In rare cases, the block is re-allocated for > another inode and written to -- subsequently, the writeback mechanism > will then flush the dirty extent header back to disk. That's why it > looks like "leaked extent data" in the data block. If this shows up even without an unclean shutdown, then it sounds like the problem is a missing bforget() call. - 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
Powered by blists - more mailing lists