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

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

2009-01-18T18:44:04+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

fs: symlink write_begin allocation context fix

2009-01-18T18:43:46+00:00

commit 54566b2c1594c2326a645a3551f9d989f7ba3c5e upstream.

With the write_begin/write_end aops, page_symlink was broken because it
could no longer pass a GFP_NOFS type mask into the point where the
allocations happened.  They are done in write_begin, which would always
assume that the filesystem can be entered from reclaim.  This bug could
cause filesystem deadlocks.

The funny thing with having a gfp_t mask there is that it doesn't really
allow the caller to arbitrarily tinker with the context in which it can be
called.  It couldn't ever be GFP_ATOMIC, for example, because it needs to
take the page lock.  The only thing any callers care about is __GFP_FS
anyway, so turn that into a single flag.

Add a new flag for write_begin, AOP_FLAG_NOFS.  Filesystems can now act on
this flag in their write_begin function.  Change __grab_cache_page to
accept a nofs argument as well, to honour that flag (while we're there,
change the name to grab_cache_page_write_begin which is more instructive
and does away with random leading underscores).

This is really a more flexible way to go in the end anyway -- if a
filesystem happens to want any extra allocations aside from the pagecache
ones in ints write_begin function, it may now use GFP_KERNEL (rather than
GFP_NOFS) for common case allocations (eg.  ocfs2_alloc_write_ctxt, for a
random example).

[kosaki.motohiro@jp.fujitsu.com: fix ubifs]
[kosaki.motohiro@jp.fujitsu.com: fix fuse]
Signed-off-by: Nick Piggin 
Reviewed-by: KOSAKI Motohiro 
Signed-off-by: KOSAKI Motohiro 
Signed-off-by: Andrew Morton 
[ Cleaned up the calling convention: just pass in the AOP flags
  untouched to the grab_cache_page_write_begin() function.  That
  just simplifies everybody, and may even allow future expansion of the
  logic.   - Linus ]
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

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

2008-11-20T02:49:58+00:00

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 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

ecryptfs: fix memory corruption when storing crypto info in xattrs

2008-10-30T18:38:46+00:00

When ecryptfs allocates space to write crypto headers into, before copying
it out to file headers or to xattrs, it looks at the value of
crypt_stat->num_header_bytes_at_front to determine how much space it
needs.  This is also used as the file offset to the actual encrypted data,
so for xattr-stored crypto info, the value was zero.

So, we kzalloc'd 0 bytes, and then ran off to write to that memory.
(Which returned as ZERO_SIZE_PTR, so we explode quickly).

The right answer is to always allocate a page to write into; the current
code won't ever write more than that (this is enforced by the
(PAGE_CACHE_SIZE - offset) length in the call to
ecryptfs_generate_key_packet_set).  To be explicit about this, we now send
in a "max" parameter, rather than magically using PAGE_CACHE_SIZE there.

Also, since the pointer we pass down the callchain eventually gets the
virt_to_page() treatment, we should be using a alloc_page variant, not
kzalloc (see also 7fcba054373d5dfc43d26e243a5c9b92069972ee)

Signed-off-by: Eric Sandeen 
Acked-by: Michael Halcrow 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] assorted path_lookup() -> kern_path() conversions

2008-10-23T09:12:52+00:00

more nameidata eviction

Signed-off-by: Al Viro

eCryptfs: remove netlink transport

2008-10-16T18:21:39+00:00

The netlink transport code has not worked for a while and the miscdev
transport is a simpler solution.  This patch removes the netlink code and
makes the miscdev transport the only eCryptfs kernel to userspace
transport.

Signed-off-by: Tyler Hicks 
Cc: Michael Halcrow 
Cc: Dustin Kirkland 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

ecryptfs: convert to use new aops

2008-10-16T18:21:39+00:00

Convert ecryptfs to use write_begin/write_end

Signed-off-by: Nick Piggin 
Signed-off-by: Badari Pulavarty 
Acked-by: Michael Halcrow 
Cc: Dave Kleikamp 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

eCryptfs: remove retry loop in ecryptfs_readdir()

2008-10-16T18:21:38+00:00

The retry block in ecryptfs_readdir() has been in the eCryptfs code base
for a while, apparently for no good reason.  This loop could potentially
run without terminating.  This patch removes the loop, instead erroring
out if vfs_readdir() on the lower file fails.

Signed-off-by: Michael Halcrow 
Reported-by: Al Viro 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

vfs: Use const for kernel parser table

2008-10-13T17:10:37+00:00

This is a much better version of a previous patch to make the parser
tables constant. Rather than changing the typedef, we put the "const" in
all the various places where its required, allowing the __initconst
exception for nfsroot which was the cause of the previous trouble.

This was posted for review some time ago and I believe its been in -mm
since then.

Signed-off-by: Steven Whitehouse 
Cc: Alexander Viro 
Signed-off-by: Linus Torvalds

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