ecryptfs sometimes seems to add trailing garbage to encrypted files

[Erik Carstensen]

Quite frequently (about once per month), a file in my ecryptfs-encrypted home directory gets a few KiBs of extra trailing garbage bytes (it's usually padded up to about 12 KiB). I have only noticed the error in git repositories so far, probably because git creates a huge number of files, and because it doesn't tend to ignore trailing garbage anywhere.

The trailing garbage usually consists mostly of zero bytes; sometimes I have also seen it contain a copy of parts of the original file.

If I re-mount the ecryptfs volume (by logging out and logging in again), the trailing garbage always disappears; this is why I think it's caused by an ecryptfs bug. I cannot rule out a faulty RAM, either (I have only reproduced it on my laptop, which doesn't have ECC RAM).

I'm using x86-64 Ubuntu 9.10, my ecryptfs volume resides on an ext4 partition.

I understand that it's impossible for you to reproduce the problem given this report, but I'm willing to put some effort in tracking down the cause of this. Do you have any ideas on how I can extract useful debugging information the next time the problem occurs?

[Dustin Kirkland  (kirkland)]

Tyler-

You've chased down a few of this git-and-bzr-on-ecryptfs issues before... Any chance you can take a look at this?

[deja_vu (deja-vu)]

I've also run into this a few times (and again just now). The files in question were padded up to 12K, also with the original file data (plus zeros).

I'm using Debian testing with a 2.6.32.3 kernel, also on an ext4 partition.

[Dustin Kirkland  (kirkland)]

Oh, wait ... are we talking about encrypted files?

All encrypted files are padded by ecryptfs. That's by design.

Are you seeing any bad data in your cleartext?

[deja_vu (deja-vu)]

The cleartext is affected. Which in my case Unison catches when I try to synchronise two computers.

I haven't tried remounting the partition, but copying the lower file somewhere else allows me to recover the original file.

[Dustin Kirkland  (kirkland)]

Okay, then I am interested in Tyler's take.

[Tyler Hicks (tyhicks)]

Erik and deja_vu - next time you see this, please do the following and report your findings:

1.) Run `stat` on the decrypted file and paste the results.
2.) Run `stat` on the encrypted file and paste the results.
3.) Run `hexdump -Cn 8` against the encrypted file and paste the results.
4.) Remount the eCryptfs mount.
5.) Repeat steps 1 through 3.

Unfortunately, if you're using encrypted filenames, it is going to be difficult to figure out the encrypted filenames in order to run stat and hexdump against those files.

Also, if you don't mind running a bleeding edge kernel, I rewrote the previously buggy truncate path and that patch (http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5f3ef64f4da1c587cdcfaaac72311225b7df094c) was released in 2.6.33-rc5. If I had to put my money on it, I'd guess that this is happening after truncating the eCryptfs inode.

I ran the git test suite in an eCryptfs mount several times and it only complained about the same tests that failed on plain ext4.

[Dustin Kirkland  (kirkland)]

If you're trying to map encrypted -> decrypted filenames, I use this
nasty little hack...

Chmod the file to a really odd permission, like "chmod 123 foo".

Then use find to locate your oddly permissioned file:
 find . -perm 123

Nasty, yes, but it works quite well.

:-Dustin

[Erik Carstensen (sandberg)]

I got the error again today, here's the output of the commands you suggested:

Before remount:

$ stat decrypted
  File: `/home/sandberg/4.2/.git/objects/49/776103dc27a460c5210dc388c98f11658a272c'
  Size: 12288 Blocks: 24 IO Block: 4096 regular file
Device: 19h/25d Inode: 474495 Links: 1
Access: (0444/-r--r--r--) Uid: ( 7654/sandberg) Gid: ( 1000/sandberg)
Access: 2010-02-05 11:45:12.000000000 +0100
Modify: 2010-02-02 18:12:07.844575172 +0100
Change: 2010-02-05 11:44:59.413928291 +0100
$ stat encrypted
  File: `/home/.ecryptfs/sandberg/.Private/ECRYPTFS_FNEK_ENCRYPTED.FWaZJpbmp..tZUREe43P.qrEcyavEC2QZFw1ykQVXjRxZSzscBFVoMzQsk--/ECRYPTFS_FNEK_ENCRYPTED.FWaZJpbmp..tZUREe43P.qrEcyavEC2QZFw10yDq6kkbjn9lr7qrnxlAvk--/ECRYPTFS_FNEK_ENCRYPTED.FWaZJpbmp..tZUREe43P.qrEcyavEC2QZFw1la465N-wDANSG0ml4M8DpU--/ECRYPTFS_FNEK_ENCRYPTED.FWaZJpbmp..tZUREe43P.qrEcyavEC2QZFw107I-eQq24En6jzyC.APn1E--/ECRYPTFS_FNEK_ENCRYPTED.FYaZJpbmp..tZUREe43P.qrEcyavEC2QZFw1zNb4HZf1uQT2mFtWKsF287cTiKR8wMOGzmCY2IvqAtFOyyN3siOt83eXT.ooIMCf'
  Size: 12288 Blocks: 24 IO Block: 4096 regular file
Device: 806h/2054d Inode: 474495 Links: 1
Access: (0444/-r--r--r--) Uid: ( 7654/sandberg) Gid: ( 1000/sandberg)
Access: 2010-02-05 11:45:12.873957850 +0100
Modify: 2010-02-02 18:12:07.844575172 +0100
Change: 2010-02-05 11:44:59.413928291 +0100
$ hexdump -Cn 8 encrypted
00000000 00 00 00 00 00 00 00 cd |........|
00000008

After remount:
$ stat decrypted
  File: `/home/sandberg/4.2/.git/objects/49/776103dc27a460c5210dc388c98f11658a272c'
  Size: 205 Blocks: 24 IO Block: 4096 regular file
Device: 16h/22d Inode: 474495 Links: 1
Access: (0444/-r--r--r--) Uid: ( 7654/sandberg) Gid: ( 1000/sandberg)
Access: 2010-02-05 11:45:12.873957850 +0100
Modify: 2010-02-02 18:12:07.844575172 +0100
Change: 2010-02-05 11:44:59.413928291 +0100
$ stat encrypted
  File: `/home/.ecryptfs/sandberg/.Private/ECRYPTFS_FNEK_ENCRYPTED.FWaZJpbmp..tZUREe43P.qrEcyavEC2QZFw1ykQVXjRxZSzscBFVoMzQsk--/ECRYPTFS_FNEK_ENCRYPTED.FWaZJpbmp..tZUREe43P.qrEcyavEC2QZFw10yDq6kkbjn9lr7qrnxlAvk--/ECRYPTFS_FNEK_ENCRYPTED.FWaZJpbmp..tZUREe43P.qrEcyavEC2QZFw1la465N-wDANSG0ml4M8DpU--/ECRYPTFS_FNEK_ENCRYPTED.FWaZJpbmp..tZUREe43P.qrEcyavEC2QZFw107I-eQq24En6jzyC.APn1E--/ECRYPTFS_FNEK_ENCRYPTED.FYaZJpbmp..tZUREe43P.qrEcyavEC2QZFw1zNb4HZf1uQT2mFtWKsF287cTiKR8wMOGzmCY2IvqAtFOyyN3siOt83eXT.ooIMCf'
  Size: 12288 Blocks: 24 IO Block: 4096 regular file
Device: 806h/2054d Inode: 474495 Links: 1
Access: (0444/-r--r--r--) Uid: ( 7654/sandberg) Gid: ( 1000/sandberg)
Access: 2010-02-05 11:45:12.873957850 +0100
Modify: 2010-02-02 18:12:07.844575172 +0100
Change: 2010-02-05 11:44:59.413928291 +0100
$ hexdump -Cn 8 encrypted
00000000 00 00 00 00 00 00 00 cd |........|
00000008

I also saved copies of the decrypted and encrypted files from before and after the remount, if you are interested (it's a rather uninteresting git tree object).

[Tyler Hicks (tyhicks)]

Hey Erik - thanks for the *great* report!

So the eCryptfs inode's i_size is out of sync from what is stored in the eCryptfs metadata (the first 8 bytes of the encrypted file). Some initial guesses are that we're missing an i_size_write() somewhere (maybe down an error path?) or we could be incorrectly passing the lower inode's i_size to i_size_write() since the upper and lower i_sizes are the same.

Are you seeing any eCryptfs error messages in the logs? I'll begin looking at the suspect code paths.

[Erik Carstensen (sandberg)]

OK, I found a few ecryptfs errors in the logs. I'm attaching the output of 'grep ryptfs syslog'.

During the logged period, the computer was never rebooted, but it was suspended a couple of times.

It seems that the errors started at feb 3, and that a pair of messages (valid ecryptfs headers not found etc) appears about every 5 mins except when the computer was suspended. It might be of interest that the computer was turned on between
Feb 4 09:50 and Feb 4 16:12:20, with no messages displayed.

There is a bunch of different messages from ecryptfs_read_lower/ecryptfs_readpage/ecryptfs_decrypt_page on Feb 4. If I recall correctly, I didn't notice the broken git files until Feb 5, though.

[Erik Carstensen (sandberg)]

I got the error again today, this time I know the error appeared within a couple of hours; during this time I could only see the following message in the logs (it appears in both syslog and kern.log, and in no other log):

Feb 17 13:36:37 ockeghem kernel: [549471.301068] ecryptfs_read_lower: octets_read = [-4]; expected [4096]
Feb 17 13:36:37 ockeghem kernel: [549471.301098] ecryptfs_read_and_validate_header_region: Error reading header region; rc = [-22]

Another possible clue: The only command I did around 13.36 was a 'git status', and when repeating the same 'git status' under strace, the only relevant system call related to the affected file is an lstat:
lstat("src/devices/PI7C9X1XX/pi7c9x110.dml", {st_mode=S_IFREG|0644, st_size=12288, ...}) = 0

[Tyler Hicks (tyhicks)]

Hi Erik - Once again, thanks for the excellent work on this bug. I've found the problem in the code, found a consistent way to reproduce the problem and will write a fix soon.

[Erik Carstensen (sandberg)]

Do you know of any way to remount an ecryptfs mount without first having to log out? That would suffice as a workaround most of the time, and would make this bug a lot less annoying for me.

[Serge Hallyn (serge-hallyn)]

Well if you're just trying to reproduce in a testcase, you can
probably just do a
custom ecryptfs mount as root:

mkdir testcrypt, testplain
cat > testme.sh << EOF
mount -t ecryptfs <options> testcrypt testplain
echo ab >> testplain/ab
umount testplain
EOF
chmod ugo+x testme.sh

for i in `seq 1 100`; do
  ./testme.sh
done

On Fri, Apr 9, 2010 at 2:38 AM, Erik Carstensen <email address hidden> wrote:
> Do you know of any way to remount an ecryptfs mount without first having
> to log out? That would suffice as a workaround most of the time, and
> would make this bug a lot less annoying for me.
>
> --
> ecryptfs sometimes seems to add trailing garbage to encrypted files
> https://bugs.launchpad.net/bugs/509180
> You received this bug notification because you are a member of eCryptfs
> Developers, which is subscribed to eCryptfs.
>
> Status in eCryptfs - Enterprise Cryptographic Filesystem: Triaged
> Status in “linux” package in Ubuntu: New
>
> Bug description:
> Quite frequently (about once per month), a file in my ecryptfs-encrypted home directory gets a few KiBs of extra trailing garbage bytes (it's usually padded up to about 12 KiB). I have only noticed the error in git repositories so far, probably because git creates a huge number of files, and because it doesn't tend to ignore trailing garbage anywhere.
>
> The trailing garbage usually consists mostly of zero bytes; sometimes I have also seen it contain a copy of parts of the original file.
>
> If I re-mount the ecryptfs volume (by logging out and logging in again), the trailing garbage always disappears; this is why I think it's caused by an ecryptfs bug. I cannot rule out a faulty RAM, either (I have only reproduced it on my laptop, which doesn't have ECC RAM).
>
> I'm using x86-64 Ubuntu 9.10, my ecryptfs volume resides on an ext4 partition.
>
> I understand that it's impossible for you to reproduce the problem given this report, but I'm willing to put some effort in tracking down the cause of this. Do you have any ideas on how I can extract useful debugging information the next time the problem occurs?
>
>
>

[Jeremy Foshee (jeremyfoshee)]

Hi Erik,

This bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? Can you try with the latest development release of Ubuntu? ISO CD images are available from http://cdimage.ubuntu.com/releases/ .

If it remains an issue, could you run the following command from a Terminal (Applications->Accessories->Terminal). It will automatically gather and attach updated debug information to this report.

apport-collect -p linux 509180

Also, if you could test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. Please let us know your results.

Thanks in advance.

    [This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

[Erik Carstensen (sandberg)]

Architecture: amd64
ArecordDevices:
 **** List of CAPTURE Hardware Devices ****
 card 0: Intel [HDA Intel], device 0: STAC92xx Analog [STAC92xx Analog]
   Subdevices: 2/2
   Subdevice #0: subdevice #0
   Subdevice #1: subdevice #1
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: sandberg 1987 F.... pulseaudio
CRDA: Error: [Errno 2] No such file or directory
Card0.Amixer.info:
 Card hw:0 'Intel'/'HDA Intel at 0xfe9fc000 irq 21'
   Mixer name : 'SigmaTel STAC9205'
   Components : 'HDA:838476a0,102801fe,00100204 HDA:14f12c06,14f1000f,00100000'
   Controls : 25
   Simple ctrls : 16
DistroRelease: Ubuntu 9.10
HibernationDevice: RESUME=UUID=5a83ce18-fd90-4c2c-ba30-96445496a9f9
InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release amd64 (20091027)
MachineType: Dell Inc. Latitude D830
Package: linux (not installed)
PccardctlIdent:
 Socket 0:
   no product info available
PccardctlStatus:
 Socket 0:
   no card
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.31-20-generic root=UUID=5f04b461-c266-4082-80b5-36054e46688e ro quiet splash
ProcEnviron:
 SHELL=/bin/bash
 PATH=(custom, user)
 LANG=en_US.UTF-8
ProcVersionSignature: Ubuntu 2.6.31-20.58-generic
RelatedPackageVersions:
 linux-backports-modules-2.6.31-20-generic N/A
 linux-firmware 1.26
Uname: Linux 2.6.31-20-generic x86_64
UserGroups: adm admin cdrom dialout fuse lpadmin mail sambashare www-data
dmi.bios.date: 06/07/2007
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A02
dmi.board.name: 0HN341
dmi.board.vendor: Dell Inc.
dmi.chassis.type: 8
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvrA02:bd06/07/2007:svnDellInc.:pnLatitudeD830:pvr:rvnDellInc.:rn0HN341:rvr:cvnDellInc.:ct8:cvr:
dmi.product.name: Latitude D830
dmi.sys.vendor: Dell Inc.

[Erik Carstensen (sandberg)]

The above data was posted with my current kernel, which is the standard one from karmic. With this setup the problem still happens. I will upgrade to lucid shortly, we'll see if the problem still exists there.

[Erik Carstensen (sandberg)]

I got the same problem again today, with a new lucid kernel.

uname -a
Linux ockeghem 2.6.32-22-generic #36-Ubuntu SMP Thu Jun 3 19:31:57 UTC 2010 x86_64 GNU/Linux

The following error message is probably related:
Jun 21 14:22:07 ockeghem kernel: [191186.234951] ecryptfs_read_and_validate_header_region: Error reading header region; rc = [-4]

Tyler, you mentioned in February that you were working on a patch; what's its status?

[Erik Carstensen (sandberg)]

I got this traceback in syslog today, together with a different set of symptoms (no signs of padded files, but a process is helplessly hung; when I try to inspect the process with gdb or strace they hang too and must be SIGKILL:ed. And I cannot suspend). ecryptfs appears in the traceback so I thought it might be another symptom of the same problem. Using the standard lucid kernel.

Jun 22 09:12:05 ockeghem kernel: [220132.893407] general protection fault: 0000
[#1] SMP
Jun 22 09:12:05 ockeghem kernel: [220132.893412] last sysfs file: /sys/devices/L
NXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT0/charge_full
Jun 22 09:12:05 ockeghem kernel: [220132.893414] CPU 0
Jun 22 09:12:05 ockeghem kernel: [220132.893416] Modules linked in: ppp_deflate
zlib_deflate bsd_comp ppp_async crc_ccitt option usbserial nls_utf8 isofs usb_st
orage usbhid hid cryptd aes_x86_64 aes_generic binfmt_misc ppdev dm_crypt snd_hd
a_codec_idt snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_
pcm snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event joydev
 snd_seq snd_timer snd_seq_device arc4 psmouse snd pcmcia soundcore snd_page_all
oc serio_raw dell_wmi iwl3945 dell_laptop dcdbas iwlcore mac80211 led_class cfg8
0211 lp parport yenta_socket rsrc_nonstatic pcmcia_core fbcon tileblit font bitb
lit softcursor vga16fb vgastate i915 drm_kms_helper ohci1394 tg3 ieee1394 ahci i
ntel_agp drm i2c_algo_bit video output
Jun 22 09:12:05 ockeghem kernel: [220132.893466] Pid: 28411, comm: simics-common
 Not tainted 2.6.32-22-generic #36-Ubuntu Latitude D830
Jun 22 09:12:05 ockeghem kernel: [220132.893469] RIP: 0010:[<ffffffff810f3859>]
 [<ffffffff810f3859>] find_get_page+0x39/0xa0
Jun 22 09:12:05 ockeghem kernel: [220132.893477] RSP: 0018:ffff880001c81918 EFL
AGS: 00010203
Jun 22 09:12:05 ockeghem kernel: [220132.893479] RAX: 07371f01fffe00ff RBX: ffff
88009b8be600 RCX: ffff8800bf6813c8
Jun 22 09:12:05 ockeghem kernel: [220132.893481] RDX: 0000000000000000 RSI: 0000
000000000040 RDI: 07371f01fffe0100
Jun 22 09:12:05 ockeghem kernel: [220132.893483] RBP: ffff880001c81928 R08: 0000000000001000 R09: 0000000000000001
Jun 22 09:12:05 ockeghem kernel: [220132.893485] R10: ffff880001c81fd8 R11: 0000000000000000 R12: 0000000000000040
Jun 22 09:12:05 ockeghem kernel: [220132.893487] R13: 0000000000000040 R14: ffff880073b69d80 R15: 0000000000000000
Jun 22 09:12:05 ockeghem kernel: [220132.893490] FS: 00007f905ffaa700(0000) GS:ffff880028200000(0000) knlGS:0000000000000000
Jun 22 09:12:05 ockeghem kernel: [220132.893492] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
Jun 22 09:12:05 ockeghem kernel: [220132.893494] CR2: 00007f905b31b008 CR3: 000000009228d000 CR4: 00000000000006f0
Jun 22 09:12:05 ockeghem kernel: [220132.893496] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Jun 22 09:12:05 ockeghem kernel: [220132.893498] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Jun 22 09:12:05 ockeghem kernel: [220132.893501] Process simics-common (pid: 28411, threadinfo ffff880001c80000, task ffff88008fd2dbc0)
Jun 22 09:12:05 ockeghem kernel: [220132.893502] Stack:
Jun 22 09:12:05 ockeghem kernel: [2201...

[Andres Jaan Tack (ajtack)]

I am running into this problem as well, running Ubuntu 10.04. I have git objects being padded up to 12kB.

Is there a formulaic workaround?

Is there some information I can provide about the incidence on my system?

[Andres Jaan Tack (ajtack)]

No need for a workaround: I think I have it, for my particular situation.

http://superuser.com/questions/162589/problem-with-git-corrupted-files/163034#163034

The offer for more details still stands, as I imagine this will occur in the future.

[Dimitri John Ledkov (ex-credativ) (dle-credativ)]

I'm on precise and this has happened to me.

Any way to do fsck on ecryptfs?

[derp herp (junkmail-trash)]

Still happening. Skype seems to exacerbate the situation.

$ find $HOME/.Private/ -size 0c -exec ls '{}' \; | wc -l
find: `/home/xxx/.Private/ECRYPTFS_FNEK_ENCRYPTED.FWYQViTKpRilBEQrvyhYzFbx53yokrMo5MdfE-hi0ZqRBXpRjN1jF7OjKU--/ECRYPTFS_FNEK_ENCRYPTED.FXYQViTKpRilBEQrvyhYzFbx53yokrMo5Mdf6-WXCmCjMQFUqNo4qH2x0HeJB218Tn.XH.DMCOJ9MTQ-': Permission denied
3
$ uname -a
Linux paperweight 3.0.0-16-generic #28-Ubuntu SMP Fri Jan 27 17:44:39 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
n

[Christian (bolek2000)]

Linux host 3.0.0-16-generic-pae #28-Ubuntu SMP Fri Jan 27 19:24:01 UTC 2012 i686 i686 i386 GNU/Linux
New Thinkpad X220, quite fresh install, all updates, using Docking station, disk never filled up
I got aware because Skype (comes up at startup) always asked me for the license agreement again, and again.

Then I found:
Feb 27 22:53:54 CS-TP kernel: [ 99.745589] Valid eCryptfs headers not found in file header region or xattr region
Feb 27 22:53:54 CS-TP kernel: [ 99.745602] Either the lower file is not in a valid eCryptfs format, or the key could not be retrieved. Plaintext passthrough mode is not enabled; returning -EIO

The I tried to remember what might have caused this...
After I tried to hibernate (what as I read now is not working with ecryptfs ?) the system could neither hibernate nor shut down anymore and always came back to the login screen. Then I had to switch it off, because I was in a hurry. Not really sure what caused the problem.
During this up and down cycle one can see different error messages.

There are 3 zero byte files, I can provide more information...

[Herton R. Krzesinski (herton)]

This bug is awaiting verification that the kernel for Lucid in -proposed solves the problem (2.6.32-40.87). Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-lucid' to 'verification-done-lucid'.

If verification is not done by one week from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

[Colin Ian King (colin-king)]

Tested and verified working for Lucid -proposed i386 2.6.32-40.87

[Launchpad Janitor (janitor)]

This bug was fixed in the package linux - 2.6.32-40.87

---------------
linux (2.6.32-40.87) lucid-proposed; urgency=low

  [Herton R. Krzesinski]

  * Release Tracking Bug
    - LP: #947375

  [ Upstream Kernel Changes ]

  * IB/mlx4: pass SMP vendor-specific attribute MADs to firmware
    - LP: #932043
  * mm/filemap_xip.c: fix race condition in xip_file_fault()
    - LP: #932043
  * NFSv4: Fix up the callers of nfs4_state_end_reclaim_reboot
    - LP: #932043
  * NFSv4: The state manager shouldn't exit on errors that were handled
    - LP: #932043
  * NFSv4: Ensure the state manager handles NFS4ERR_NO_GRACE correctly
    - LP: #932043
  * NFSv4: Handle NFS4ERR_GRACE when recovering an expired lease.
    - LP: #932043
  * NFSv4: Fix open recovery
    - LP: #932043
  * rpc client can not deal with ENOSOCK, so translate it into ENOCONN
    - LP: #932043
  * udf: Mark LVID buffer as uptodate before marking it dirty
    - LP: #932043
  * eCryptfs: Infinite loop due to overflow in ecryptfs_write()
    - LP: #932043
  * atmel_lcdfb: fix usage of CONTRAST_CTR in suspend/resume
    - LP: #932043
  * Staging: asus_oled: fix image processing
    - LP: #932043
  * Staging: android: binder: Don't call dump_stack in binder_vma_open
    - LP: #932043
  * Staging: android: binder: Fix crashes when sharing a binder file
    between processes
    - LP: #932043
  * usb: gadget: zero: fix bug in loopback autoresume handling
    - LP: #932043
  * usb: Skip PCI USB quirk handling for Netlogic XLP
    - LP: #932043
  * USB: usbserial: add new PID number (0xa951) to the ftdi driver
    - LP: #932043
  * mmc: cb710 core: Add missing spin_lock_init for irq_lock of struct
    cb710_chip
    - LP: #932043
  * net: fix sk_forward_alloc corruptions
    - LP: #932043
  * net: sock_queue_err_skb() dont mess with sk_forward_alloc
    - LP: #932043
  * Linux 2.6.32.57
    - LP: #932043
  * Ban ecryptfs over ecryptfs
    - LP: #932987
  * eCryptfs: Remove mmap from directory operations
    - LP: #400443
  * eCryptfs: Use notify_change for truncating lower inodes
    - LP: #451368
  * ecryptfs: read on a directory should return EISDIR if not supported
    - LP: #719691
  * eCryptfs: Remove extra d_delete in ecryptfs_rmdir
    - LP: #723518
  * eCryptfs: Clear i_nlink in rmdir
    - LP: #723518
  * KVM: Device assignment permission checks
    - LP: #897812
    - CVE-2011-4347
  * block: Fix io_context leak after clone with CLONE_IO
    - LP: #940743
    - CVE-2012-0879
  * block: Fix io_context leak after failure of clone with CLONE_IO
    - LP: #940743
    - CVE-2012-0879
  * eCryptfs: Handle failed metadata read in lookup
    - LP: #509180
  * drm/i915: Fix TV Out refresh rate.
    - LP: #945114
  * Linux 2.6.32.57+drm33.23
    - LP: #945114
 -- Herton Ronaldo Krzesinski <email address hidden> Mon, 05 Mar 2012 16:09:18 -0300

[Sam Liddicott (sam-liddicott)]

On Thu, Mar 22, 2012 at 2:55 PM, Launchpad Bug Tracker <
<email address hidden>> wrote:

> This bug was fixed in the package linux - 2.6.32-40.87
>
>
hurrah, and thanks to everyone involved.

[Colin Ian King (colin-king)]

verified on 2.6.38-14.58 -proposed with ext2, ext3, ext4, xfs, btrfs lower file systems.

[Adam Porter (alphapapa)]

The reports seem to indicate that this isn't fixed in Oneiric. Should that still be marked "Fix Released"?

[Clint Byrum (clint-fewbar)]

Excerpts from Adam Porter's message of Sat Mar 31 23:16:30 UTC 2012:
> The reports seem to indicate that this isn't fixed in Oneiric. Should
> that still be marked "Fix Released"?
>

It was confirmed to be fixed in at least this context. If there is an
additional case where it is not, then that would be a new bug, please
report a new bug with 'apport-bug linux'. You will want to reference
this bug report in that one, suggesting that it may be a regression or
at the very least, has similar symptoms.

[Colin Ian King (colin-king)]

@Adam, it was verified for 2.6.38-14.58, which was in proposed at the time of testing. Check that you are using this kernel before filing a new bug. Thanks.

[JD Rogers (rogersjd)]

Colin, I'm confused.
Oneiric currently uses 3.0.0-17 and the messages are certainly not fixed for me.
This bug is listed as "fix released" for oneiric as well as older 9.10 in the original bug report. Should a new bug be opened for oneiric and 3.0 kernels even though 11.10 is listed as affected by this bug?

[Colin Ian King (colin-king)]

@JD Rogers, the relevant fix is in Oneiric, commit 3aeb86ea4cd15f728147a3bd5469a205ada8c767, so perhaps you are seeing another related issue.

[JD Rogers (rogersjd)]

@Colin, ok, I'll gather more info and see if I need to file a new bug. Thanks.

[James Gifford (jamesgifford)]

This still is happening, its also in 12.04.

[vkapas (vkapas)]

The bug still is happening in Ubuntu 10.04.3.

$ uname -a
Linux dell-inspiron-1501 2.6.32-41-generic #88-Ubuntu SMP Thu Mar 29 13:10:32 UTC 2012 x86_64 GNU/Linux

$ mount -l
/dev/sda1 on / type ext4 (rw,errors=remount-ro)
proc on /proc type proc (rw,noexec,nosuid,nodev)
/dev/sda5 on /home type xfs (rw)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)
/user/set/.Private on /home/user type ecryptfs (ecryptfs_check_dev_ruid,ecryptfs_sig=34e21478f0216127,ecryptfs_fnek_sig=681325906c7014cb,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs)

In /var/log/messages:

Apr 26 22:29:39 dell-inspiron-1501 kernel: [174527.741111] Either the lower file is not in a valid eCryptfs format, or the key could not be retrieved. Plaintext passthrough mode is not enabled; returning -EIO
Apr 26 22:34:39 dell-inspiron-1501 kernel: [174827.558166] Either the lower file is not in a valid eCryptfs format, or the key could not be retrieved. Plaintext passthrough mode is not enabled; returning -EIO
Apr 26 22:39:39 dell-inspiron-1501 kernel: [175128.064340] Either the lower file is not in a valid eCryptfs format, or the key could not be retrieved. Plaintext passthrough mode is not enabled; returning -EIO
Apr 26 22:44:39 dell-inspiron-1501 kernel: [175427.531031] Either the lower file is not in a valid eCryptfs format, or the key could not be retrieved. Plaintext passthrough mode is not enabled; returning -EIO
Apr 26 22:49:39 dell-inspiron-1501 kernel: [175727.510556] Either the lower file is not in a valid eCryptfs format, or the key could not be retrieved. Plaintext passthrough mode is not enabled; returning -EIO

And this is last entries before the computer freezes.

[vkapas (vkapas)]

>The bug still is happening in Ubuntu 10.04.3.
10.04.4

[hanfkeks (c-weber23)]

Confirming it for 12.04, did not occur for me with earlier Ubuntu releases.

[Martin Faltesek (martin-faltesek)]

Just encountered this bug in 12.04. Due to bugs in evolution, I was trying to export my folders
by saving to mbox format, and ran across another evolution bug where it wrote out gigabytes of
data to the mbox file (the folder is only a few megabytes) filling up the home file system. I now have
corrupted files in evolution and chrome and not sure where else (95 files are corrupted).

This is a dangerous bug and needs mentioning in the release notes, especially given how long it's apparently
been in the wild.

[Martin Faltesek (martin-faltesek)]

I forgot to mention that remounting or rebooting does not resolve the corruption.

[Christian Mertes (cmertes)]

Yep Martin, this is the reason why I moved away from ecryptfs. It's dangerous and alpha and should not be used productively by anyone. Use a LUKS encrypted partition on $HOME/Private with pam_mount. With an LVM you can even grow it, albeit not automatically.

[Torsten Krah (tkrah)]

Maybe someone with sufficient permission can reopen the state of lucid + add series precise to this bug to track this non fixed bug.

[Tyler Hicks (tyhicks)]

On 2012-04-26 19:16:25, vkapas wrote:
> The bug still is happening in Ubuntu 10.04.3.

<snip>

> Apr 26 22:29:39 dell-inspiron-1501 kernel: [174527.741111] Either the lower file is not in a valid eCryptfs format, or the key could not be retrieved. Plaintext passthrough mode is not enabled; returning -EIO

Seeing this particular error message alone does not mean that you've hit
this bug. It could be seen from the result of this bug, but there are
other reasons that you may see this error message.

Please see comment #78 for a 'find' command that should show you which
file is triggering this error.

[Tyler Hicks (tyhicks)]

On 2012-04-29 18:49:40, hanfkeks wrote:
> Confirming it for 12.04, did not occur for me with earlier Ubuntu
> releases.

Hello - Can you please be very clear about what it is that you're
confirming? There are a number of unrelated issues mentioned in the
comments to this bug and it can be difficult for developers to
understand if it this bug is actually not fixed or if there is a
slightly different bug affecting you. Thanks!

[Tyler Hicks (tyhicks)]

On 2012-05-04 03:23:27, Martin Faltesek wrote:
> Just encountered this bug in 12.04. Due to bugs in evolution, I was trying to export my folders
> by saving to mbox format, and ran across another evolution bug where it wrote out gigabytes of
> data to the mbox file (the folder is only a few megabytes) filling up the home file system. I now have
> corrupted files in evolution and chrome and not sure where else (95 files are corrupted).

This is a completely unrelated (but serious!) issue. Please file a new
bug for this. In the meantime, I'll try to recreate what you're seeing.

[Rhadamantys (rhadamantys)]

Interestingly, I haven't had that message with kernel 2.6.38-14-generic on 11.04, but now, whith 12.04, I get it regulary and the kernel panics right after that. Is this coincidence? Is there a way to check the integrity of the whole eCryptFS?

[Christian Mertes (cmertes)]

Tyler Hicks (tyhicks) wrote on 2012-05-04:

> This is a completely unrelated (but serious!) issue. Please file a new
> bug for this. In the meantime, I'll try to recreate what you're seeing.

Well yes and no, I reported this issue in Bug #957843
https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/957843 which had been marked a duplicate of this bug. I agree though that this was just a lazy way to get rid of one bug.

[Vadim Peretokin (vperetokin)]

I was still getting this error after reinstalling 12.04 on a brand-new SSD. So this issue still spawns.

As per comment 78, I got several files with the io error. I take it these files were unreachable because programs using those files were affected.

I'm not certain why did this corruption happen. Is encryptfs not reliable?

[Vadim Peretokin (vperetokin)]

Deleting them seems to have worked:

vadi@gooseberry:~$ find . -type f -exec cat {} \; > /dev/null
cat: ./.config/google-chrome/.com.google.Chrome.ok97wK: Input/output error
cat: ./.config/google-chrome/.com.google.Chrome.vQ5Sr2: Input/output error
cat: ./.config/google-chrome/.com.google.Chrome.wVBbQ2: Input/output error
cat: ./.config/google-chrome/Default/Cookies-journal: Input/output error
find: `./.gvfs': Transport endpoint is not connected
cat: ./.Skype/shared.xml: Input/output error
vadi@gooseberry:~$ rm ./.Skype/shared.xml
vadi@gooseberry:~$ rm ./.config/google-chrome/.com.google.Chrome.ok97wK
vadi@gooseberry:~$ rm ./.config/google-chrome/.com.google.Chrome.vQ5Sr2
vadi@gooseberry:~$ rm ./.config/google-chrome/.com.google.Chrome.wVBbQ2
vadi@gooseberry:~$ rm ./.config/google-chrome/Default/Cookies-journal
vadi@gooseberry:~$ find . -type f -exec cat {} \; > /dev/null
find: `./.gvfs': Transport endpoint is not connected
vadi@gooseberry:~$

[Charl P. Botha (cpbotha)]

It seems like this bug (also see duplicate https://bugs.launchpad.net/ubuntu/+source/linux/+bug/529002 ) is unfortunately still very much present on 12.04.

$ uname -a
Linux cpbotha-e6410 3.2.0-24-generic #38-Ubuntu SMP Tue May 1 16:18:50 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

$ find $HOME/.Private/ -size 0c -exec ls '{}' \; | wc -l
253

Indeed, my dropbox is stuck on indexing 247 files (this is how I noticed). When I go to one of the files in question:

$ ls -la envedit.exe.manifest
-rw-rw-r-- 1 cpbotha cpbotha 0 May 14 17:17 envedit.exe.manifest

$ cat envedit.exe.manifest
cat: envedit.exe.manifest: Input/output error

... and then in my dmesg:

[ 6554.071505] Valid eCryptfs headers not found in file header region or xattr region, inode 4882470
[ 6554.071511] Either the lower file is not in a valid eCryptfs format, or the key could not be retrieved. Plaintext passthrough mode is not enabled; returning -EIO

In other words, I have at least 253 files (some of them more important than envedit.exe.manifest) that are at risk.

[software-schlosser (software-schlosser)]

Got this back after upgrading to 12.04 too. 4 of 84 encrypted files are affected.

[Charl P. Botha (cpbotha)]

For those of you seeing specifically the 0-length lower file resulting in IO errors in the mounted ecryptfs filesystem, please go to the report for that: bug #957843 -- remember indicate that the bug affects you, and to subscribe to it. (both will increase the bug heat)

[Kai Falkenberg (wooosh)]

Hi,

I can confirm the bug's presence in 12.04:

$ uname -a
Linux ninux 3.0.0-19-generic #33-Ubuntu SMP Thu Apr 19 19:05:57 UTC 2012 i686 i686 i386 GNU/Linux

$ find $HOME/.Private/ -size 0c -exec ls '{}' \; | wc -l
4

[ 444.916666] Valid eCryptfs headers not found in file header region or xattr region, inode 2890741
[ 444.916670] Either the lower file is not in a valid eCryptfs format, or the key could not be retrieved. Plaintext passthrough mode is not enabled; returning -EIO

and
$ cat $HOME/.ICEauthority
cat: .ICEauthority: Input/Output error

Can't login to Xfce with this user.. :(

[Kai Falkenberg (wooosh)]

Sorry, just read #213. Please ignore my previous comment. :-)

[ilUomo (menchini)]

After trying the 'delete zero-length files in $HOME/.Private, I found that deleting $HOME/.Skype and restarting skype fixed it for me! (oneric on a Lenovo W520)

[J (jonathan-vola)]

I believe I'm seeing this on 12.04 with ecryptfs home folder: I have no 0-length errors (In fact I have no errors at all concerning ecryptfs in my logs) but files are being corrupted regularly.

Specifically: Downloading torrents (Which are supposed to be verified while downloading) then manually verifying the data results in the client finding a corrupted piece then redownloading it and saying it's 100% again. Verifying manually again makes it just do that same thing over.

Using the file then throws errors about corrupted source files - in one case I had a zip file (Downloaded through firefox - not torrent) that wouldn't even open.

None of these problems occur if I download directly to a non-encrypted partition.

[Scott Kitterman (kitterman)]

You need to file a new bug for your problem.

[Pavlo Verba (pavlo.s.verba)]

Is there any chance that this issue might be negatively and severely affecting startup time of a system?

[Tim Gardner (timg-tpi)]

Maverick is no longer supported.