From patchwork Fri Mar 16 09:16:51 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Colin Ian King X-Patchwork-Id: 147168 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 48E65B6FA2 for ; Fri, 16 Mar 2012 20:17:05 +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 1S8THL-00029S-Gm; Fri, 16 Mar 2012 09:16:55 +0000 Received: from youngberry.canonical.com ([91.189.89.112]) by chlorine.canonical.com with esmtp (Exim 4.71) (envelope-from ) id 1S8THJ-00029C-1v for kernel-team@lists.ubuntu.com; Fri, 16 Mar 2012 09:16:53 +0000 Received: from cpc19-craw6-2-0-cust5.croy.cable.virginmedia.com ([77.102.228.6] helo=localhost) by youngberry.canonical.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1S8THI-0006en-Uo for kernel-team@lists.ubuntu.com; Fri, 16 Mar 2012 09:16:53 +0000 From: Colin King To: kernel-team@lists.ubuntu.com Subject: [PATCH 1/1] eCryptfs: Clear ECRYPTFS_NEW_FILE flag during truncate Date: Fri, 16 Mar 2012 09:16:51 +0000 Message-Id: <1331889411-29401-2-git-send-email-colin.king@canonical.com> X-Mailer: git-send-email 1.7.9.1 In-Reply-To: <1331889411-29401-1-git-send-email-colin.king@canonical.com> References: <1331889411-29401-1-git-send-email-colin.king@canonical.com> 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: Colin Ian King 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 Signed-off-by: Colin Ian King Acked-by: Andy Whitcroft --- fs/ecryptfs/inode.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/fs/ecryptfs/inode.c b/fs/ecryptfs/inode.c index 645da17..3c1dbc0 100644 --- a/fs/ecryptfs/inode.c +++ b/fs/ecryptfs/inode.c @@ -777,6 +777,9 @@ static int truncate_upper(struct dentry *dentry, struct iattr *ia, 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); + /* Set up a fake ecryptfs file, this is used to interface with * the file in the underlying filesystem so that the * truncation has an effect there as well. */