linux-toradex.git/fs/ecryptfs, branch v2.6.31.3

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

push BKL down into ->put_super

2009-06-12T01:36:07+00:00

Move BKL into ->put_super from the only caller.  A couple of
filesystems had trivial enough ->put_super (only kfree and NULLing of
s_fs_info + stuff in there) to not get any locking: coda, cramfs, efs,
hugetlbfs, omfs, qnx4, shmem, all others got the full treatment.  Most
of them probably don't need it, but I'd rather sort that out individually.
Preferably after all the other BKL pushdowns in that area.

[AV: original used to move lock_super() down as well; these changes are
removed since we don't do lock_super() at all in generic_shutdown_super()
now]
[AV: fuse, btrfs and xfs are known to need no damn BKL, exempt]

Signed-off-by: Christoph Hellwig 
Signed-off-by: Al Viro

Convert obvious places to deactivate_locked_super()

2009-05-09T14:49:40+00:00

Signed-off-by: Al Viro

eCryptfs: Fix min function comparison warning

2009-04-27T18:31:12+00:00

This warning shows up on 64 bit builds:

fs/ecryptfs/inode.c:693: warning: comparison of distinct pointer types
lacks a cast

Signed-off-by: Tyler Hicks