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:

bd4f0fe8bb7c73c738e1e11bc90d6e2cf9c6e20e
fed8859b3ab94274c986cbdf7d27130e0545f02c

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...