Hardy ecryptfs can cause data loss
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Linux |
Unknown
|
Unknown
|
|||
linux (Ubuntu) |
Fix Released
|
Medium
|
Tim Gardner | ||
Hardy |
Fix Released
|
Medium
|
Tim Gardner |
Bug Description
This bug can cause data loss on an ecryptfs mounted filesystem.
The test case looks like this:
# mkdir /tmp/dir1 /tmp/dir2
# mount -t ecryptfs /tmp/dir1 /tmp/dir2
(any ecryptfs mount options are fine, choose defaults)
# cp /usr/share/
# umount /tmp/dir2
# mount -t ecryptfs /tmp/dir1 /tmp/dir2
(choose same options/passphrase as last mount)
# echo foo >> /tmp/dir2/GPL-3
# tail /tmp/dir2/GPL-3
# reset
You will see badly decrypted data printed to screen, whereas you should see the GPLv3 plus "foo" printed to screen. The data in this file is permanently hosed.
The fix for this bug was applied upstream against 2.6.26, and is already in the intrepid kernel.
The git commit diff can be seen here:
* http://
I will gladly test a new Hardy kernel as soon as it becomes available.
:-Dustin
Changed in linux: | |
importance: | Undecided → Medium |
milestone: | none → ubuntu-8.04.2 |
Changed in linux: | |
status: | Fix Committed → Confirmed |
SRU Justification:
Impact: ecryptfs can cause loss of data in certain scenarios
Patch Description: cherry-picked 2.6.25.y d3e49afbb661096 13c3474f2273f58 30ac2dcb09. The page decrypt calls in ecryptfs_write() are both pointless and buggy. Pointless because ecryptfs_ get_locked_ page() has already brought the page up to date, and buggy because prior mmap writes will just be blown away by the decrypt call. This patch also removes the declaration of a now-nonexistent function ecryptfs_ write_zeros( ).
Patch: http:// kernel. ubuntu. com/git? p=ubuntu/ ubuntu- hardy.git; a=commit; h=b85452a23dcde ddc4a4ae1816501 e80a16bb14a8
Test Case: see Bug decscription