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: <20131017150630.GC11404@dhcp-13-216.nay.redhat.com> Date: Thu, 17 Oct 2013 23:06:30 +0800 From: Eryu Guan <guaneryu@...il.com> To: Lukáš Czerner <lczerner@...hat.com> Cc: linux-ext4@...r.kernel.org, Theodore Ts'o <tytso@....edu> Subject: Re: [PATCH] ext4: don't cache out of order extents On Thu, Oct 17, 2013 at 03:44:35PM +0200, Lukáš Czerner wrote: > On Thu, 17 Oct 2013, Eryu Guan wrote: > > > Date: Thu, 17 Oct 2013 17:27:53 +0800 > > From: Eryu Guan <guaneryu@...il.com> > > To: linux-ext4@...r.kernel.org > > Cc: Eryu Guan <guaneryu@...il.com>, Theodore Ts'o <tytso@....edu> > > Subject: [PATCH] ext4: don't cache out of order extents > > > > A corrupted ext4 may have out of order leaf extents, i.e. > > > > extent: lblk 0--1023, len 1024, pblk 9217, flags: LEAF UNINIT > > extent: lblk 1000--2047, len 1024, pblk 10241, flags: LEAF UNINIT > > ^^^^ overlap with previous extent > > > > Reading such extent could hit BUG_ON() in ext4_es_cache_extent(). > > > > BUG_ON(end < lblk); > > > > The problem is that __read_extent_tree_block() tries to cache holes as > > well but assumes 'lblk' is greater than 'prev' and passes underflowed > > length to ext4_es_cache_extent(). > > > > I hit this when fuzz testing ext4, and am able to reproduce it by > > modifying the on-disk extent by hand. > > > > Ran xfstests on patched ext4 and no regression. > > So what will happen with the file system with this patch when > presented with such corruption ? > > It seems to me that ext4_es_cache_extent() will happily skip this > extent because it will find that this particular offset is already > in the tree. Hence we'll have a gap in the status tree which really > should not be there and I suspect that something bad will happen. > > I think that we should deal with this corruption immediately when we > spot it there, not just hide it. Yes, agreed, we should validate the extent not cover the corruption as Ted pointed out. Don't know why I didn't think about it more in the first place.. Thanks! Eryu Guan -- 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