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

eCryptfs: Prevent lower dentry from going negative during unlink (CVE-2009-2908)

2009-10-12T18:33:06+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 
Cc: Chuck Ebbert 
Signed-off-by: Greg Kroah-Hartman

eCryptfs: parse_tag_3_packet check tag 3 packet encrypted key size (CVE-2009-2407)

2009-07-30T23:06:12+00:00

commit f151cd2c54ddc7714e2f740681350476cda03a28 upstream.

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 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

eCryptfs: Check Tag 11 literal data buffer size (CVE-2009-2406)

2009-07-30T23:06:12+00:00

commit 6352a29305373ae6196491e6d4669f301e26492e upstream.

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 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

eCryptfs: check readlink result was not an error before using it

2009-01-18T18:35:40+00:00

commit a17d5232de7b53d34229de79ec22f4bb04adb7e4 upstream.

The result from readlink is being used to index into the link name
buffer without checking whether it is a valid length. If readlink
returns an error this will fault or cause memory corruption.

Cc: Tyler Hicks 
Cc: Dustin Kirkland 
Cc: ecryptfs-devel@lists.launchpad.net
Signed-off-by: Duane Griffin 
Acked-by: Michael Halcrow 
Acked-by: Tyler Hicks 
Signed-off-by: Al Viro 
Signed-off-by: Greg Kroah-Hartman

eCryptfs: Allocate up to two scatterlists for crypto ops on keys

2008-12-05T18:55:10+00:00

commit ac97b9f9a2d0b83488e0bbcb8517b229d5c9b142 upstream.

I have received some reports of out-of-memory errors on some older AMD
architectures.  These errors are what I would expect to see if
crypt_stat->key were split between two separate pages.  eCryptfs should
not assume that any of the memory sent through virt_to_scatterlist() is
all contained in a single page, and so this patch allocates two
scatterlist structs instead of one when processing keys.  I have received
confirmation from one person affected by this bug that this patch resolves
the issue for him, and so I am submitting it for inclusion in a future
stable release.

Note that virt_to_scatterlist() runs sg_init_table() on the scatterlist
structs passed to it, so the calls to sg_init_table() in
decrypt_passphrase_encrypted_session_key() are redundant.

Signed-off-by: Michael Halcrow 
Reported-by: Paulo J. S. Silva 
Cc: "Leon Woestenberg" 
Cc: Tim Gardner 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

eCryptfs: use page_alloc not kmalloc to get a page of memory

2008-07-28T23:30:21+00:00

With SLUB debugging turned on in 2.6.26, I was getting memory corruption
when testing eCryptfs.  The root cause turned out to be that eCryptfs was
doing kmalloc(PAGE_CACHE_SIZE); virt_to_page() and treating that as a nice
page-aligned chunk of memory.  But at least with SLUB debugging on, this
is not always true, and the page we get from virt_to_page does not
necessarily match the PAGE_CACHE_SIZE worth of memory we got from kmalloc.

My simple testcase was 2 loops doing "rm -f fileX; cp /tmp/fileX ." for 2
different multi-megabyte files.  With this change I no longer see the
corruption.

Signed-off-by: Eric Sandeen 
Acked-by: Michael Halcrow 
Acked-by: Rik van Riel 
Cc: 		[2.6.25.x, 2.6.26.x]
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] kill nameidata passing to permission(), rename to inode_permission()

2008-07-27T00:53:31+00:00

Incidentally, the name that gives hundreds of false positives on grep
is not a good idea...

Signed-off-by: Al Viro

[patch 5/5] vfs: remove mode parameter from vfs_symlink()

2008-07-27T00:53:18+00:00

Remove the unused mode parameter from vfs_symlink and callers.

Thanks to Tetsuo Handa for noticing.

CC: Tetsuo Handa 
Signed-off-by: Miklos Szeredi

[PATCH] sanitize ->permission() prototype

2008-07-27T00:53:14+00:00

* kill nameidata * argument; map the 3 bits in ->flags anybody cares
  about to new MAY_... ones and pass with the mask.
* kill redundant gfs2_iop_permission()
* sanitize ecryptfs_permission()
* fix remaining places where ->permission() instances might barf on new
  MAY_... found in mask.

The obvious next target in that direction is permission(9)

folded fix for nfs_permission() breakage from Miklos Szeredi 

Signed-off-by: Al Viro

SL*B: drop kmem cache argument from constructor

2008-07-26T19:00:07+00:00

Kmem cache passed to constructor is only needed for constructors that are
themselves multiplexeres.  Nobody uses this "feature", nor does anybody uses
passed kmem cache in non-trivial way, so pass only pointer to object.

Non-trivial places are:
	arch/powerpc/mm/init_64.c
	arch/powerpc/mm/hugetlbpage.c

This is flag day, yes.

Signed-off-by: Alexey Dobriyan 
Acked-by: Pekka Enberg 
Acked-by: Christoph Lameter 
Cc: Jon Tollefson 
Cc: Nick Piggin 
Cc: Matt Mackall 
[akpm@linux-foundation.org: fix arch/powerpc/mm/hugetlbpage.c]
[akpm@linux-foundation.org: fix mm/slab.c]
[akpm@linux-foundation.org: fix ubifs]
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds