kernel/git/stable/linux.git/fs/ecryptfs, branch linux-2.6.31.y

ecryptfs: use after free

2010-04-01T22:55:34+00:00

commit ece550f51ba175c14ec3ec047815927d7386ea1f upstream. The "full_alg_name" variable is used on a couple error paths, so we shouldn't free it until the end. Signed-off-by: Dan Carpenter Signed-off-by: Tyler Hicks Signed-off-by: Greg Kroah-Hartman

ecryptfs: initialize private persistent file before dereferencing pointer

2010-04-01T22:55:34+00:00

commit e27759d7a333d1f25d628c4f7caf845c51be51c2 upstream. Ecryptfs_open dereferences a pointer to the private lower file (the one stored in the ecryptfs inode), without checking if the pointer is NULL. Right afterward, it initializes that pointer if it is NULL. Swap order of statements to first initialize. Bug discovered by Duckjin Kang. Signed-off-by: Duckjin Kang Signed-off-by: Erez Zadok Cc: Dustin Kirkland Cc: Al Viro Signed-off-by: Tyler Hicks Signed-off-by: Greg Kroah-Hartman

ima: ecryptfs fix imbalance message

2009-10-12T19:40:13+00:00

commit 36520be8e32b49bd85a63b7b8b40cd07c3da59a5 upstream. The unencrypted files are being measured. Update the counters to get rid of the ecryptfs imbalance message. (http://bugzilla.redhat.com/519737) Reported-by: Sachin Garg Cc: Eric Paris Cc: Dustin Kirkland Cc: James Morris Cc: David Safford Signed-off-by: Mimi Zohar Signed-off-by: Tyler Hicks Signed-off-by: Greg Kroah-Hartman

eCryptfs: Prevent lower dentry from going negative during unlink

2009-10-05T16:31:42+00:00

commit 9c2d2056647790c5034d722bd24e9d913ebca73c upstream. When calling vfs_unlink() on the lower dentry, d_delete() turns the dentry into a negative dentry when the d_count is 1. This eventually caused a NULL pointer deref when a read() or write() was done and the negative dentry's d_inode was dereferenced in ecryptfs_read_update_atime() or ecryptfs_getxattr(). Placing mutt's tmpdir in an eCryptfs mount is what initially triggered the oops and I was able to reproduce it with the following sequence: open("/tmp/upper/foo", O_RDWR|O_CREAT|O_EXCL|O_NOFOLLOW, 0600) = 3 link("/tmp/upper/foo", "/tmp/upper/bar") = 0 unlink("/tmp/upper/foo") = 0 open("/tmp/upper/bar", O_RDWR|O_CREAT|O_NOFOLLOW, 0600) = 4 unlink("/tmp/upper/bar") = 0 write(4, "eCryptfs test\n"..., 14 +++ killed by SIGKILL +++ https://bugs.launchpad.net/ecryptfs/+bug/387073 Reported-by: Loïc Minier Cc: Serge Hallyn Cc: Dave Kleikamp Cc: ecryptfs-devel@lists.launchpad.net Signed-off-by: Tyler Hicks Signed-off-by: Greg Kroah-Hartman

eCryptfs: Validate global auth tok keys

2009-10-05T16:31:41+00:00

commit 3891959846709a19f76628e33478cd85edb0e79f upstream. When searching through the global authentication tokens for a given key signature, verify that a matching key has not been revoked and has not expired. This allows the `keyctl revoke` command to be properly used on keys in use by eCryptfs. Acked-by: Serge Hallyn Cc: ecryptfs-devel@lists.launchpad.net Signed-off-by: Tyler Hicks Signed-off-by: Greg Kroah-Hartman

eCryptfs: Filename encryption only supports password auth tokens

2009-10-05T16:31:41+00:00

commit df6ad33ba1b9846bd5f0e2b9016c30c20bc2d948 upstream. Returns -ENOTSUPP when attempting to use filename encryption with something other than a password authentication token, such as a private token from openssl. Using filename encryption with a userspace eCryptfs key module is a future goal. Until then, this patch handles the situation a little better than simply using a BUG_ON(). Acked-by: Serge Hallyn Cc: ecryptfs-devel@lists.launchpad.net Signed-off-by: Tyler Hicks Signed-off-by: Greg Kroah-Hartman

eCryptfs: Check for O_RDONLY lower inodes when opening lower files

2009-10-05T16:31:40+00:00

commit ac22ba23b659e34a5961aec8c945608e471b0d5b upstream. If the lower inode is read-only, don't attempt to open the lower file read/write and don't hand off the open request to the privileged eCryptfs kthread for opening it read/write. Instead, only try an unprivileged, read-only open of the file and give up if that fails. This patch fixes an oops when eCryptfs is mounted on top of a read-only mount. Acked-by: Serge Hallyn Cc: Eric Sandeen Cc: Dave Kleikamp Cc: ecryptfs-devel@lists.launchpad.net Signed-off-by: Tyler Hicks Signed-off-by: Greg Kroah-Hartman

eCryptfs: Handle unrecognized tag 3 cipher codes

2009-10-05T16:31:40+00:00

commit b0105eaefa7cce8f4a941d0fc6354b250d30e745 upstream. Returns an error when an unrecognized cipher code is present in a tag 3 packet or an ecryptfs_crypt_stat cannot be initialized. Also sets an crypt_stat->tfm error pointer to NULL to ensure that it will not be incorrectly freed in ecryptfs_destroy_crypt_stat(). Acked-by: Serge Hallyn Cc: ecryptfs-devel@lists.launchpad.net Signed-off-by: Tyler Hicks Signed-off-by: Greg Kroah-Hartman

eCryptfs: parse_tag_3_packet check tag 3 packet encrypted key size

2009-07-28T21:26:06+00:00

The parse_tag_3_packet function does not check if the tag 3 packet contains a encrypted key size larger than ECRYPTFS_MAX_ENCRYPTED_KEY_BYTES. Signed-off-by: Ramon de Carvalho Valle [tyhicks@linux.vnet.ibm.com: Added printk newline and changed goto to out_free] Signed-off-by: Tyler Hicks Cc: stable@kernel.org (2.6.27 and 30) Signed-off-by: Linus Torvalds

eCryptfs: Check Tag 11 literal data buffer size

2009-07-28T21:26:06+00:00

Tag 11 packets are stored in the metadata section of an eCryptfs file to store the key signature(s) used to encrypt the file encryption key. After extracting the packet length field to determine the key signature length, a check is not performed to see if the length would exceed the key signature buffer size that was passed into parse_tag_11_packet(). Thanks to Ramon de Carvalho Valle for finding this bug using fsfuzzer. Signed-off-by: Tyler Hicks Cc: stable@kernel.org (2.6.27 and 30) Signed-off-by: Linus Torvalds