Comment 86 for bug 745836

Tyler Hicks (tyhicks) wrote :

This turned out to be a tricky one. It is definitely an eCryptfs bug. The upstream fix that I thought would solve this issue ended up not being the right fix. Instead, it turned out to be the following two commits:


However, I didn't write those patches as bug fixes. I was simply cleaning out some crufty looking code. It turned out to be buggy code, too.

Creating a file, extending that file, the file's pages being reclaimed, finally followed by reading the file is what triggers this. In the case of this bug report, the system being under memory pressure is what forced the file's pages out of the page cache.

The easiest way to reproduce the bug is with the following shell commands:

$ touch foo && truncate -s 4096 foo && sync && echo 1 | sudo tee /proc/sys/vm/drop_caches && hexdump -C foo

hexdump should show a file filled with zeroes, but it doesn't.

Data corruption is a possibility if the file is written to before the eCryptfs directory is unmounted.

It looks like all kernels before 2.6.39 are affected, possibly all the way back to the beginning of eCryptfs being merged upstream. Patch, with all the technical eCryptfs details in the commit message, to follow...