Bug 830456 - Booting with kernel 3.4.0 mounted luks files are incorrecly readed
Booting with kernel 3.4.0 mounted luks files are incorrecly readed
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
17
x86_64 Linux
unspecified Severity urgent
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-09 15:36 EDT by Marco Motta
Modified: 2012-06-21 13:37 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-06-21 13:37:52 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Marco Motta 2012-06-09 15:36:12 EDT
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 12:52:38 EDT
I upgrade my kernel to 3.4.2-4.fc17.x86_64, and the problem is solved.
Comment 2 Josh Boyer 2012-06-21 13:37:52 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.