linux-ext4 - [PATCH] ext4: fix BUG_ON() in ext4_ext_insert

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: <1317206703-5604-1-git-send-email-tm@tao.ma>
Date:	Wed, 28 Sep 2011 18:45:03 +0800
From:	Tao Ma <tm@....ma>
To:	linux-ext4@...r.kernel.org
Cc:	Greg Kroah-Hartman <greg@...ah.com>,
	"Theodore Ts'o" <tytso@....edu>,
	Xiaoyun Mao <xiaoyun.maoxy@...yun-inc.com>,
	Yingbin Wang <yingbin.wangyb@...yun-inc.com>,
	Jia Wan <jia.wanj@...yun-inc.com>
Subject: [PATCH] ext4: fix BUG_ON() in ext4_ext_insert_extent()

Hi Ted,
On 09/28/2011 03:35 AM, Ted Ts'o wrote:
> On Mon, Sep 26, 2011 at 10:28:08AM -0400, Konrad Rzeszutek Wilk wrote:
>>> > >  
>>> > >    Attached is the fix, verified in our env. 
>> > 
>> > So.. you are asking for this upstream git commit to be back-ported
>> > to 2.6.32, right?
> I'm curious --- is there a good reason why Xen users are using an
> upstream 2.6.32 kernel?  If they are using a distro kernel, fine, but
> then the distro kernel should be providing the support.  But at this
> point, 2.6.32 is so positively *ancient* that, I'm personally not
> interesting in providing free, unpaid distro support for users who
> aren't willing to either (a) pay $$$ and get a supported distro
> kernel, or (b) use a much more modern kernel.  At this point, Guest
> and Host Xen support is available in 3.0 kernels, so there's really no
> excuse, right?
actually this bug does show up in 2.6.39 and I think stable tree still
needs this fix. After some careful test, my colleague has generated
the patch. Please considering ack it so that Greg can add it into the
stable tree.

Thanks
Tao

>From 600d493b14ebd776cf8ea0e9dcdccc0d54200403 Mon Sep 17 00:00:00 2001
From: Zheng Liu <wenqing.lz@...bao.com>
Date: Wed, 28 Sep 2011 16:26:05 +0800
Subject: [PATCH] ext4: fix BUG_ON() in ext4_ext_insert_extent()

We will meet with a BUG_ON() if following script is run.

mkfs.ext4 -b 4096 /dev/sdb1 1000000
mount -t ext4 /dev/sdb1 /mnt/sdb1
fallocate -l 100M /mnt/sdb1/test
sync
for((i=0;i<170;i++))
do
        dd if=/dev/zero of=/mnt/sdb1/test conv=notrunc bs=256k count=1 seek=`expr $i \* 2`
done
umount /mnt/sdb1
mount -t ext4 /dev/sdb1 /mnt/sdb1
dd if=/dev/zero of=/mnt/sdb1/test conv=notrunc bs=256k count=1 seek=341
umount /mnt/sdb1
mount /dev/sdb1 /mnt/sdb1
dd if=/dev/zero of=/mnt/sdb1/test conv=notrunc bs=256k count=1 seek=340
sync

The reason is that it forgot to mark dirty when splitting two extents in
ext4_ext_convert_to_initialized(). Althrough ex has been updated in memory,
it is not dirtied both in ext4_ext_convert_to_initialized() and
ext4_ext_insert_extent(). The disk layout is corrupted. Then it will meet with
a BUG_ON() when writting at the start of that extent again.

Cc: stable@...nel.org #for 2.6.39
Cc: Greg Kroah-Hartman <greg@...ah.com>
Cc: "Theodore Ts'o" <tytso@....edu>
Cc: Xiaoyun Mao <xiaoyun.maoxy@...yun-inc.com>
Cc: Yingbin Wang <yingbin.wangyb@...yun-inc.com>
Cc: Jia Wan <jia.wanj@...yun-inc.com>
Signed-off-by: Zheng Liu <wenqing.lz@...bao.com>
---
 fs/ext4/extents.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
index 4890d6f..cd20425 100644
--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -2607,6 +2607,7 @@ static int ext4_ext_convert_to_initialized(handle_t *handle,
 		ex1 = ex;
 		ex1->ee_len = cpu_to_le16(map->m_lblk - ee_block);
 		ext4_ext_mark_uninitialized(ex1);
+		ext4_ext_dirty(handle, inode, path + depth);
 		ex2 = &newex;
 	}
 	/*
-- 
1.7.4.1

--
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