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

eCryptfs: NULL crypt_stat dereference during lookup

2009-03-22T18:20:43+00:00

If ecryptfs_encrypted_view or ecryptfs_xattr_metadata were being
specified as mount options, a NULL pointer dereference of crypt_stat
was possible during lookup.

This patch moves the crypt_stat assignment into
ecryptfs_lookup_and_interpose_lower(), ensuring that crypt_stat
will not be NULL before we attempt to dereference it.

Thanks to Dan Carpenter and his static analysis tool, smatch, for
finding this bug.

Signed-off-by: Tyler Hicks 
Acked-by: Dustin Kirkland 
Cc: Dan Carpenter 
Cc: Serge Hallyn 
Signed-off-by: Linus Torvalds

eCryptfs: Allocate a variable number of pages for file headers

2009-03-22T18:20:43+00:00

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: Greg KH 
Cc: dann frazier 
Cc: Serge E. Hallyn 
Cc: Florian Streibelt 
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds

eCryptfs: don't encrypt file key with filename key

2009-03-14T18:57:22+00:00

eCryptfs has file encryption keys (FEK), file encryption key encryption
keys (FEKEK), and filename encryption keys (FNEK).  The per-file FEK is
encrypted with one or more FEKEKs and stored in the header of the
encrypted file.  I noticed that the FEK is also being encrypted by the
FNEK.  This is a problem if a user wants to use a different FNEK than
their FEKEK, as their file contents will still be accessible with the
FNEK.

This is a minimalistic patch which prevents the FNEKs signatures from
being copied to the inode signatures list.  Ultimately, it keeps the FEK
from being encrypted with a FNEK.

Signed-off-by: Tyler Hicks 
Cc: Serge Hallyn 
Acked-by: Dustin Kirkland 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

eCryptfs: Regression in unencrypted filename symlinks

2009-02-07T02:36:40+00:00

The addition of filename encryption caused a regression in unencrypted
filename symlink support.  ecryptfs_copy_filename() is used when dealing
with unencrypted filenames and it reported that the new, copied filename
was a character longer than it should have been.

This caused the return value of readlink() to count the NULL byte of the
symlink target.  Most applications don't care about the extra NULL byte,
but a version control system (bzr) helped in discovering the bug.

Signed-off-by: Tyler Hicks 
Signed-off-by: Linus Torvalds

fs/Kconfig: move ecryptfs out

2009-01-22T10:15:56+00:00

Signed-off-by: Alexey Dobriyan

fs/ecryptfs/inode.c: cleanup kerneldoc

2009-01-06T23:59:22+00:00

Arguments lower_dentry and ecryptfs_dentry in ecryptfs_create_underlying_file()
have been merged into dentry, now fix it.

Signed-off-by: Qinghuang Feng 
Cc: Randy Dunlap 
Cc: Michael Halcrow 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

eCryptfs: Clean up ecryptfs_decode_from_filename()

2009-01-06T23:59:22+00:00

Flesh out the comments for ecryptfs_decode_from_filename(). Remove the
return condition, since it is always 0.

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

eCryptfs: kerneldoc for ecryptfs_parse_tag_70_packet()

2009-01-06T23:59:22+00:00

Kerneldoc updates for ecryptfs_parse_tag_70_packet().

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

eCryptfs: Fix data types (int/size_t)

2009-01-06T23:59:22+00:00

Correct several format string data type specifiers.  Correct filename size
data types; they should be size_t rather than int when passed as
parameters to some other functions (although note that the filenames will
never be larger than int).

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

eCryptfs: Replace %Z with %z

2009-01-06T23:59:22+00:00

%Z is a gcc-ism. Using %z instead.

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