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

eCryptfs: Allocate a variable number of pages for file headers

2009-03-23T21:55:32+00:00

commit 8faece5f906725c10e7a1f6caf84452abadbdc7b upstream.

When allocating the memory used to store the eCryptfs header contents, a
single, zeroed page was being allocated with get_zeroed_page().
However, the size of an eCryptfs header is either PAGE_CACHE_SIZE or
ECRYPTFS_MINIMUM_HEADER_EXTENT_SIZE (8192), whichever is larger, and is
stored in the file's private_data->crypt_stat->num_header_bytes_at_front
field.

ecryptfs_write_metadata_to_contents() was using
num_header_bytes_at_front to decide how many bytes should be written to
the lower filesystem for the file header.  Unfortunately, at least 8K
was being written from the page, despite the chance of the single,
zeroed page being smaller than 8K.  This resulted in random areas of
kernel memory being written between the 0x1000 and 0x1FFF bytes offsets
in the eCryptfs file headers if PAGE_SIZE was 4K.

This patch allocates a variable number of pages, calculated with
num_header_bytes_at_front, and passes the number of allocated pages
along to ecryptfs_write_metadata_to_contents().

Thanks to Florian Streibelt for reporting the data leak and working with
me to find the problem.  2.6.28 is the only kernel release with this
vulnerability.  Corresponds to CVE-2009-0787

Signed-off-by: Tyler Hicks 
Acked-by: Dustin Kirkland 
Reviewed-by: Eric Sandeen 
Reviewed-by: Eugene Teo 
Cc: dann frazier 
Cc: Serge E. Hallyn 
Cc: Florian Streibelt 
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: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