linux-toradex.git/fs/ecryptfs, branch v2.6.27.13 Linux kernel for Apalis and Colibri modules eCryptfs: check readlink result was not an error before using it 2009-01-18T18:35:40+00:00 Duane Griffin duaneg@dghda.com 2008-12-19T20:47:10+00:00 a48a68982ebfabe032a0ae8a60c4ca6f1b180ade 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 <tyhicks@linux.vnet.ibm.com> Cc: Dustin Kirkland <kirkland@canonical.com> Cc: ecryptfs-devel@lists.launchpad.net Signed-off-by: Duane Griffin <duaneg@dghda.com> Acked-by: Michael Halcrow <mhalcrow@us.ibm.com> Acked-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
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 <tyhicks@linux.vnet.ibm.com>
Cc: Dustin Kirkland <kirkland@canonical.com>
Cc: ecryptfs-devel@lists.launchpad.net
Signed-off-by: Duane Griffin <duaneg@dghda.com>
Acked-by: Michael Halcrow <mhalcrow@us.ibm.com>
Acked-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
eCryptfs: Allocate up to two scatterlists for crypto ops on keys 2008-12-05T18:55:10+00:00 Michael Halcrow mhalcrow@us.ibm.com 2008-11-19T23:36:28+00:00 c53459aa96901e6d21d69acff88fb77759edd3f7 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 <mhalcrow@us.ibm.com> Reported-by: Paulo J. S. Silva <pjssilva@ime.usp.br> Cc: "Leon Woestenberg" <leon.woestenberg@gmail.com> Cc: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
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 <mhalcrow@us.ibm.com>
Reported-by: Paulo J. S. Silva <pjssilva@ime.usp.br>
Cc: "Leon Woestenberg" <leon.woestenberg@gmail.com>
Cc: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
eCryptfs: use page_alloc not kmalloc to get a page of memory 2008-07-28T23:30:21+00:00 Eric Sandeen sandeen@redhat.com 2008-07-28T22:46:39+00:00 7fcba054373d5dfc43d26e243a5c9b92069972ee 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 <sandeen@redhat.com> Acked-by: Michael Halcrow <mhalcrow@us.ibm.com> Acked-by: Rik van Riel <riel@redhat.com> Cc: <stable@kernel.org> [2.6.25.x, 2.6.26.x] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
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 <sandeen@redhat.com>
Acked-by: Michael Halcrow <mhalcrow@us.ibm.com>
Acked-by: Rik van Riel <riel@redhat.com>
Cc: <stable@kernel.org>		[2.6.25.x, 2.6.26.x]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[PATCH] kill nameidata passing to permission(), rename to inode_permission() 2008-07-27T00:53:31+00:00 Al Viro viro@zeniv.linux.org.uk 2008-07-22T04:07:17+00:00 f419a2e3b64def707e1384ee38abb77f99af5f6d Incidentally, the name that gives hundreds of false positives on grep is not a good idea... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> 
Incidentally, the name that gives hundreds of false positives on grep
is not a good idea...

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
[patch 5/5] vfs: remove mode parameter from vfs_symlink() 2008-07-27T00:53:18+00:00 Miklos Szeredi mszeredi@suse.cz 2008-06-24T14:50:16+00:00 db2e747b14991a4c6a5c98b0e5f552a193237c03 Remove the unused mode parameter from vfs_symlink and callers. Thanks to Tetsuo Handa for noticing. CC: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: Miklos Szeredi <mszeredi@suse.cz> 
Remove the unused mode parameter from vfs_symlink and callers.

Thanks to Tetsuo Handa for noticing.

CC: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
[PATCH] sanitize ->permission() prototype 2008-07-27T00:53:14+00:00 Al Viro viro@zeniv.linux.org.uk 2008-07-16T01:03:57+00:00 e6305c43eda10ebfd2ad9e35d6e172ccc7bb3695 * 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 <mszeredi@suse.cz> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> 
* 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 <mszeredi@suse.cz>

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
SL*B: drop kmem cache argument from constructor 2008-07-26T19:00:07+00:00 Alexey Dobriyan adobriyan@gmail.com 2008-07-26T02:45:34+00:00 51cc50685a4275c6a02653670af9f108a64e01cf 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 <adobriyan@gmail.com> Acked-by: Pekka Enberg <penberg@cs.helsinki.fi> Acked-by: Christoph Lameter <cl@linux-foundation.org> Cc: Jon Tollefson <kniht@linux.vnet.ibm.com> Cc: Nick Piggin <nickpiggin@yahoo.com.au> Cc: Matt Mackall <mpm@selenic.com> [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 <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
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 <adobriyan@gmail.com>
Acked-by: Pekka Enberg <penberg@cs.helsinki.fi>
Acked-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Jon Tollefson <kniht@linux.vnet.ibm.com>
Cc: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Matt Mackall <mpm@selenic.com>
[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 <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
eCryptfs: Make all persistent file opens delayed 2008-07-24T17:47:31+00:00 Michael Halcrow mhalcrow@us.ibm.com 2008-07-24T04:30:08+00:00 391b52f98cf2e9bff227dad8bf9ea206fec43fa4 There is no good reason to immediately open the lower file, and that can cause problems with files that the user does not intend to immediately open, such as device nodes. This patch removes the persistent file open from the interpose step and pushes that to the locations where eCryptfs really does need the lower persistent file, such as just before reading or writing the metadata stored in the lower file header. Two functions are jumping to out_dput when they should just be jumping to out on error paths. This patch also fixes these. Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
There is no good reason to immediately open the lower file, and that can
cause problems with files that the user does not intend to immediately
open, such as device nodes.

This patch removes the persistent file open from the interpose step and
pushes that to the locations where eCryptfs really does need the lower
persistent file, such as just before reading or writing the metadata
stored in the lower file header.

Two functions are jumping to out_dput when they should just be jumping to
out on error paths.  This patch also fixes these.

Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
eCryptfs: do not try to open device files on mknod 2008-07-24T17:47:31+00:00 Michael Halcrow mhalcrow@us.ibm.com 2008-07-24T04:30:07+00:00 72b55fffd631a89e5be6fe1b4f2565bc4cd90deb When creating device nodes, eCryptfs needs to delay actually opening the lower persistent file until an application tries to open. Device handles may not be backed by anything when they first come into existence. [Valdis.Kletnieks@vt.edu: build fix] Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Cc: <Valdis.Kletnieks@vt.edu} Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
When creating device nodes, eCryptfs needs to delay actually opening the lower
persistent file until an application tries to open.  Device handles may not be
backed by anything when they first come into existence.

[Valdis.Kletnieks@vt.edu: build fix]
Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com>
Cc: <Valdis.Kletnieks@vt.edu}
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
ecryptfs: inode.c mmap.c use unaligned byteorder helpers 2008-07-24T17:47:31+00:00 Harvey Harrison harvey.harrison@gmail.com 2008-07-24T04:30:07+00:00 0a688ad713949643e201431d3f4a4ceddfeb70ca Fixe sparse warnings: fs/ecryptfs/inode.c:368:15: warning: cast to restricted __be64 fs/ecryptfs/mmap.c:385:12: warning: incorrect type in assignment (different base types) fs/ecryptfs/mmap.c:385:12: expected unsigned long long [unsigned] [assigned] [usertype] file_size fs/ecryptfs/mmap.c:385:12: got restricted __be64 [usertype] <noident> fs/ecryptfs/mmap.c:428:12: warning: incorrect type in assignment (different base types) fs/ecryptfs/mmap.c:428:12: expected unsigned long long [unsigned] [assigned] [usertype] file_size fs/ecryptfs/mmap.c:428:12: got restricted __be64 [usertype] <noident> Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> Cc: Michael Halcrow <mhalcrow@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
Fixe sparse warnings:
fs/ecryptfs/inode.c:368:15: warning: cast to restricted __be64
fs/ecryptfs/mmap.c:385:12: warning: incorrect type in assignment (different base types)
fs/ecryptfs/mmap.c:385:12:    expected unsigned long long [unsigned] [assigned] [usertype] file_size
fs/ecryptfs/mmap.c:385:12:    got restricted __be64 [usertype] <noident>
fs/ecryptfs/mmap.c:428:12: warning: incorrect type in assignment (different base types)
fs/ecryptfs/mmap.c:428:12:    expected unsigned long long [unsigned] [assigned] [usertype] file_size
fs/ecryptfs/mmap.c:428:12:    got restricted __be64 [usertype] <noident>

Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Cc: Michael Halcrow <mhalcrow@us.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>