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: <524C4F2A.4010609@zynstra.com> Date: Wed, 2 Oct 2013 17:51:54 +0100 From: James Dingwall <james.dingwall@...stra.com> To: Jan Kara <jack@...e.cz> CC: <linux-ext4@...r.kernel.org> Subject: Re: ext[234] data corruption (Linux 3.8, 3.9 / Xen) Jan Kara wrote: > Hello, > > On Thu 26-09-13 08:22:40, James Dingwall wrote: >>> Hi, >>> >>> We have observed a data corruption bug in a database created by >>> the postmap command (BDB file) under the following conditions: >>> >>> Xen domU guest kernel 3.8, 3.9 (3.5, 3.10, 3.11 don't show the >>> behaviour 3.6 and 3.7 are unknown) >>> dom0 Xen 4.2.1 / kernel 3.8 or Xen 4.3.0 / kernel 3.11 >>> The guest has a passed through block device (phy:/ or file:/) >>> The filesytem on the passed through device is ext2/3/4 with a 1k >>> block size > Thanks for report! So have you really tried with all three filesystems? > And don't you have EXT4_USE_FOR_EXT23 set by any chance? There were some > changes to ext4 writeback path and extent status tree. So for ext4 I could > understand the problem got introduced and fixed. But ext2/3 didn't see any > significant changes for a long time... EXT4_USE_FOR_EXT23 doesn't seem to be in use and it isn't listed in /proc/config.gz, perhaps a parent option that would make it available isn't set? # zgrep EXT[234] /proc/config.gz CONFIG_EXT2_FS=y CONFIG_EXT2_FS_XATTR=y CONFIG_EXT2_FS_POSIX_ACL=y CONFIG_EXT2_FS_SECURITY=y # CONFIG_EXT2_FS_XIP is not set CONFIG_EXT3_FS=y # CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set CONFIG_EXT3_FS_XATTR=y CONFIG_EXT3_FS_POSIX_ACL=y CONFIG_EXT3_FS_SECURITY=y CONFIG_EXT4_FS=m CONFIG_EXT4_FS_POSIX_ACL=y CONFIG_EXT4_FS_SECURITY=y # CONFIG_EXT4_DEBUG is not set >>> By examining a strace of the postmap command we produced a short >>> piece of code (at the bottom) which demonstrates the problem. If >>> this is executed in a loop such as: >>> >>> #!/bin/bash >>> for i in $(seq 1 5) ; do >>> mount /dev/xvde1 /mnt >>> pushd /mnt> /dev/null >>> echo "checksums after mount" >>> md5sum testcase.bin >>> [ "${i}" = "1" ] && ./a.out >>> echo "checksums before umount" >>> md5sum testcase.bin >>> popd> /dev/null >>> umount /mnt >>> done > I'll see if I can reproduce this to investigate. > > <snip output of script> > Well, you can always use 'git bisect' to find the commit that fixed this. In the end it seemed that the problem was fixed in a 3.10 stable release (I had originally tested with 3.10.10 which it may have been helpful to mention:) as it does happen with a kernel built from tag v3.10. Bisecting gives commit 7b2b160da7661bb2ade3f924b1bd3e3084e53341 (in xen-blkfront.c) which solves the observed issue although the commit message seems to indicate it is a resolution for a problem of a different nature. My knowledge of kernel internals isn't enough to understand why this is the fix. Since the commit applies cleanly to the Ubuntu 3.8 LTS tree (where we found the original problem) we'll do some testing and then open it as an Ubuntu bug if it looks good. <snip test program> -- 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