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: <5281A8A3.80604@gmail.com> Date: Mon, 11 Nov 2013 20:03:47 -0800 From: Gordon Messmer <gordon.messmer@...il.com> To: linux-ext4@...r.kernel.org Subject: kernel panic using external journal and snapshots I'm developing backup infrastructure for Linux using snapshots. One of the supported configurations is EXT4 on LVM, but I think I've come across a bug. I'm currently testing on CentOS 6, with kernel 2.6.32-358.6.1.el6.x86_64 If I create a snapshot of a filesystem with an external journal, and mount that snapshot while the original filesystem is mounted, the system will usually kernel panic. If it does not panic, then the kernel will later refuse to mount it because "External journal has more than one user." So, the first bug seems to be that ext4 doesn't check the external journal before mounting the new snapshot to ensure that the journal is not in use. Expected behavior is that the kernel would refuse to mount a filesystem whose journal already has a "user" in order to prevent a kernel panic. If that were the extent of the problem, I probably wouldn't bother reporting the issue. However, the kernel will STILL panic if I use tune2fs to remove the journal, and even if I use tune2fs to create a new internal journal. The second bug, then, seems to be that once an ext4 filesystem has an external journal, that journal will continue to be used after it has been removed, and even if it is replaced with an internal journal. The following commands were used to test the problem. These are basically the commands run by the "snapshot" application. It sets a minimum snapshot size of 10% of the volume size, then reads the size of the volume and the size remaining in the volume group. It creates a uuid for the snapshot name, then creates the new snapshot. I use tune2fs first to verify that there is a journal device recorded, then remove the journal. Afterward, I read the value again and find no external journal recorded. When the filesystem is mounted, the kernel will usually panic. Is this a known bug? I haven't yet built a newer system to test the effects on the current kernel version. min_size=10 lvsize=$(lvs --noheadings --units m --nosuffix -o lv_size "VolGroup/lv_var" | cut -f1 -d.) vgfree=$(vgs --noheadings --units m --nosuffix -o vg_free "/dev/VolGroup" | cut -f1 -d.) test "$vgfree" -gt $(( $lvsize * $min_size / 100 )) || echo Not enough free space on "/dev/VolGroup" for snapshot uuid=$(uuidgen) lvcreate -s -n "lv_var-snap-${uuid}" -L "$(( $lvsize * $min_size / 100 ))"m "VolGroup/lv_var" Rounding up size to full physical extent 128.00 MiB Logical volume "lv_var-snap-66c41691-21c0-4db2-8af2-09a13d87a881" created tune2fs -l "/dev/VolGroup/lv_var-snap-${uuid}" | grep "^Journal device:" Journal device: 0xfd04 tune2fs -O ^has_journal "/dev/VolGroup/lv_var-snap-${uuid}" tune2fs 1.41.12 (17-May-2010) Journal removed tune2fs -l "/dev/VolGroup/lv_var-snap-${uuid}" | grep "^Journal device:" mount "/dev/VolGroup/lv_var-snap-${uuid}" /mnt * kernel panic * https://bitbucket.org/gordonmessmer/dragonsdawn-snapshot -- 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