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... -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/745836 Title: encrypted swap corrupts application stack/heap [was: soffice.bin SIGSEGV cppu::throwException()] To manage notifications about this bug go to: https://bugs.launchpad.net/df-libreoffice/+bug/745836/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
