[PATCH 0/1][Luicd][SRU] eCryptfs: Clear ECRYPTFS_NEW_FILE flag during truncate

Colin King colin.king at canonical.com
Fri Mar 16 09:16:50 UTC 2012

From: Colin Ian King <colin.king at canonical.com>

BugLink: http://bugs.launchpad.net/bugs/745836

SRU justification:


The ECRYPTFS_NEW_FILE crypt_stat flag is set upon creation of a new
eCryptfs file. When the flag is set, eCryptfs reads directly from the
lower filesystem when bringing a page up to date. This means that no
offset translation (for the eCryptfs file metadata in the lower file)
and no decryption is performed. The flag is cleared just before the
first write is completed (at the beginning of ecryptfs_write_begin()).

It was discovered that if a new file was created and then extended with
truncate, the ECRYPTFS_NEW_FILE flag was not cleared. If pages
corresponding to this file are ever reclaimed, any subsequent reads
would result in userspace seeing eCryptfs file metadata and encrypted
file contents instead of the expected decrypted file contents.

Data corruption is possible if the file is written to before the
eCryptfs directory is unmounted. The data written will be copied into
pages which have been read directly from the lower file rather than
zeroed pages, as would be expected after extending the file with

Fix: Clear the ECRYPTFS_NEW_FILE flags if set. Fix was originally from
Tyler Hicks and needed a little massaging to apply for the current Lucid,
see https://launchpadlibrarian.net/82254993/0001-eCryptfs-Clear-ECRYPTFS_NEW_FILE-flag-during-truncat.patch


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

and hexdump should show a file filled with zeroes. Without the fix the file
is full of garbage, whereas with the fix the file is full of zeros as 

Colin Ian King (1):
  eCryptfs: Clear ECRYPTFS_NEW_FILE flag during truncate

 fs/ecryptfs/inode.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

More information about the kernel-team mailing list