From patchwork Sun Oct 9 11:12:02 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tim Gardner X-Patchwork-Id: 118584 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from chlorine.canonical.com (chlorine.canonical.com [91.189.94.204]) by ozlabs.org (Postfix) with ESMTP id CB765B70D6 for ; Sun, 9 Oct 2011 22:12:34 +1100 (EST) Received: from localhost ([127.0.0.1] helo=chlorine.canonical.com) by chlorine.canonical.com with esmtp (Exim 4.71) (envelope-from ) id 1RCrIk-0001Hg-JJ; Sun, 09 Oct 2011 11:12:14 +0000 Received: from mail.tpi.com ([70.99.223.143]) by chlorine.canonical.com with esmtp (Exim 4.71) (envelope-from ) id 1RCrIh-0001HW-NE for kernel-team@lists.ubuntu.com; Sun, 09 Oct 2011 11:12:11 +0000 Received: from lochsa.rtg.net (mail.tpi.com [70.99.223.143]) by mail.tpi.com (Postfix) with ESMTP id 6E0692EF5AA for ; Sun, 9 Oct 2011 04:11:16 -0700 (PDT) Received: by lochsa.rtg.net (Postfix, from userid 1000) id E5225F88CF; Sun, 9 Oct 2011 05:12:02 -0600 (MDT) To: kernel-team@lists.ubuntu.com Subject: Natty SRU: eCryptfs: Clear ECRYPTFS_NEW_FILE flag during truncate Message-Id: <20111009111202.E5225F88CF@lochsa.rtg.net> Date: Sun, 9 Oct 2011 05:12:02 -0600 (MDT) From: timg@tpi.com (Tim Gardner) X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.13 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Sender: kernel-team-bounces@lists.ubuntu.com Errors-To: kernel-team-bounces@lists.ubuntu.com From 27ed7cb2b00512e81016419715c1d9b6794b06ae Mon Sep 17 00:00:00 2001 From: Tyler Hicks Date: Fri, 7 Oct 2011 15:54:26 -0500 Subject: [PATCH] eCryptfs: Clear ECRYPTFS_NEW_FILE flag during truncate BugLink: http://bugs.launchpad.net/bugs/745836 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 truncate. This flag, and the functionality that used it, was removed in upstream kernels in 2.6.39 with the following commits: bd4f0fe8bb7c73c738e1e11bc90d6e2cf9c6e20e fed8859b3ab94274c986cbdf7d27130e0545f02c Signed-off-by: Tyler Hicks --- fs/ecryptfs/inode.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/fs/ecryptfs/inode.c b/fs/ecryptfs/inode.c index b592938..e47b5a4 100644 --- a/fs/ecryptfs/inode.c +++ b/fs/ecryptfs/inode.c @@ -785,7 +785,11 @@ static int truncate_upper(struct dentry *dentry, struct iattr *ia, lower_ia->ia_valid &= ~ATTR_SIZE; goto out; } + crypt_stat = &ecryptfs_inode_to_private(dentry->d_inode)->crypt_stat; + if (crypt_stat->flags & ECRYPTFS_NEW_FILE) + crypt_stat->flags &= ~(ECRYPTFS_NEW_FILE); + /* Switch on growing or shrinking file */ if (ia->ia_size > i_size) { char zero[] = { 0x00 };