Bug 830456

Summary: Booting with kernel 3.4.0 mounted luks files are incorrecly readed
Product: [Fedora] Fedora Reporter: Marco Motta <marco.motta>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 17CC: gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda, marco.motta
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-06-21 17:37:52 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Marco Motta 2012-06-09 19:36:12 UTC
Description of problem:

Booting with kernel 3.4.0-1.fc17, if I mount a crypted luks file some files are (random for any mount) incorrectly readed.This is a very serious bug.

Version-Release number of selected component (if applicable):

kernel 3.4.0-1.fc17

How reproducible:

Boot with a kernel 3.3.7-1.fc17, and create 2 luks file with this code (as root):

LOOP=`losetup -f`
dd if=/dev/urandom of=/home/user/test1.luks bs=1M count=200
losetup "$LOOP" /home/user/test1.luks
cryptsetup --verbose --cipher "aes-cbc-essiv:sha256" --key-size 256 --verify-passphrase luksFormat "$LOOP"
cryptsetup luksOpen "$LOOP" test1
mke2fs -j /dev/mapper/test1
mkdir -p /media/test1
mount -t ext3 /dev/mapper/test1 /media/test1

And the same for test2.luks. Fill /media/test1 and /media/test2 with the same files, umount them, reboot with kernel 3.4.0-1.fc17, remount them and test for differences between the files.

In "Step to Reproduce" i use two files created for this test.

Steps to Reproduce:
1. Download test1.luks (200M) from https://docs.google.com/file/d/0B7v7BOTAcGzpZWFjUGowRndGUmc/edit?pli=1
2. Download test2.luks (200M) from https://docs.google.com/file/d/0B7v7BOTAcGzpX2VIWVJMYW9CM1k/edit?pli=1
3. Save them as /home/user/test1.luks and /home/user/test2.luks (use your username instead of "user")
4. type, in a terminal, as root:
mkdir -p /media/test1
LOOP=`losetup -f`
losetup "$LOOP" /home/user/test1.luks
cryptsetup luksOpen "$LOOP" test1# type s1rl%go/&v.23lm45AwDkC,+^pkR84F
mount -t ext3 /dev/mapper/test1 /media/test1
mkdir -p /media/test2
LOOP=`losetup -f`
losetup "$LOOP" /home/user/test2.luks
cryptsetup luksOpen "$LOOP" test2# type s1rl%go/&v.23lm45AwDkC,+^pkR84F
mount -t ext3 /dev/mapper/test2 /media/test2
cd /media/test1
find . -type f | while read FILE; do diff "$FILE" "../test2/$FILE"; done
  
Actual results:
If you boot with kernel 3.3.7-1.fc17, the line
find . -type f | while read FILE; do diff "$FILE" "../test2/$FILE"; done
has no output (the files in test1.luks and test2.luks are the same).
If, instead, you boot with kernel 3.4.0-1.fc17 and repeat the passes 1. 2. 3. 4., you see more lines of different files with non-ascii characters (but the files are NOT different!). If you open one of the "different" files with gedit or other program, you can sed this lines. If you umount and remount the files, the "different" files are not the same.

Expected results:

The files in test1.luks and test2.luks are the same; there should be no output of diff!

Additional info:

I tried with a 20M file too, but I have not found errors. I don't know if the error occours only with relatively large files (200M, in my case), or the error is only in a few files, and with 20M I must try more.
I found this bug in three different computer with Fedora 17, only using 3.4.0-1.fc17 kernel. The ram is ok, and is respectively 4G, 4G and 3G in this pc.

Comment 1 Marco Motta 2012-06-21 16:52:38 UTC
I upgrade my kernel to 3.4.2-4.fc17.x86_64, and the problem is solved.

Comment 2 Josh Boyer 2012-06-21 17:37:52 UTC
Thanks for letting us know.  There were a few dm/md, ext4, and one radix_tree fix that might have contributed to this.

If you see it again, please reopen.