linux-toradex.git/fs, branch v2.6.32.45

proc: restrict access to /proc/PID/io

2011-08-08T17:23:19+00:00

commit 1d1221f375c94ef961ba8574ac4f85c8870ddd51 upstream.

/proc/PID/io may be used for gathering private information.  E.g.  for
openssh and vsftpd daemons wchars/rchars may be used to learn the
precise password length.  Restrict it to processes being able to ptrace
the target process.

ptrace_may_access() is needed to prevent keeping open file descriptor of
"io" file, executing setuid binary and gathering io information of the
setuid'ed process.

Signed-off-by: Vasiliy Kulikov 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

cifs: check for NULL session password

2011-08-08T17:23:16+00:00

commit 24e6cf92fde1f140d8eb0bf7cd24c2c78149b6b2 upstream.

It's possible for a cifsSesInfo struct to have a NULL password, so we
need to check for that prior to running strncmp on it.

Signed-off-by: Jeff Layton 
Signed-off-by: Steve French 
Signed-off-by: Greg Kroah-Hartman

cifs: fix NULL pointer dereference in cifs_find_smb_ses

2011-08-08T17:23:16+00:00

commit fc87a40677bbe0937e2ff0642c7e83c9a4813f3d upstream.

cifs_find_smb_ses assumes that the vol->password field is a valid
pointer, but that's only the case if a password was passed in via
the options string. It's possible that one won't be if there is
no mount helper on the box.

Reported-by: diabel 
Signed-off-by: Jeff Layton 
Signed-off-by: Steve French 
Signed-off-by: Greg Kroah-Hartman

cifs: clean up cifs_find_smb_ses (try #2)

2011-08-08T17:23:16+00:00

commit 4ff67b720c02c36e54d55b88c2931879b7db1cd2 upstream.

This patch replaces the earlier patch by the same name. The only
difference is that MAX_PASSWORD_SIZE has been increased to attempt to
match the limits that windows enforces.

Do a better job of matching sessions by authtype. Matching by username
for a Kerberos session is incorrect, and anonymous sessions need special
handling.

Also, in the case where we do match by username, we also need to match
by password. That ensures that someone else doesn't "borrow" an existing
session without needing to know the password.

Finally, passwords can be longer than 16 bytes. Bump MAX_PASSWORD_SIZE
to 512 to match the size that the userspace mount helper allows.

Signed-off-by: Jeff Layton 
Signed-off-by: Steve French 
[dannf: backported to Debian's 2.6.32]
Cc: Moritz Muehlenhoff 
Signed-off-by: Greg Kroah-Hartman

Revert "block: rescan partitions on invalidated devices on -ENOMEDIA too"

2011-08-08T17:23:15+00:00

This reverts commit 5b2745db12a3f97a9ec9efd4ffa077da707d3e4c (commit
02e352287a40bd456eb78df705bf888bc3161d3f upstream)

This should have only been commited on .38 and newer, not older kernels
like this one, sorry.

Cc: Tejun Heo 
Cc: David Zeuthen 
Cc: Martin Pitt 
Cc: Kay Sievers 
Cc: Alan Cox 
Cc: Jens Axboe 
Cc: Andi Kleen 
Signed-off-by: Greg Kroah-Hartman

ext3: Fix oops in ext3_try_to_allocate_with_rsv()

2011-08-08T17:23:13+00:00

commit ad95c5e9bc8b5885f94dce720137cac8fa8da4c9 upstream.

Block allocation is called from two places: ext3_get_blocks_handle() and
ext3_xattr_block_set(). These two callers are not necessarily synchronized
because xattr code holds only xattr_sem and i_mutex, and
ext3_get_blocks_handle() may hold only truncate_mutex when called from
writepage() path. Block reservation code does not expect two concurrent
allocations to happen to the same inode and thus assertions can be triggered
or reservation structure corruption can occur.

Fix the problem by taking truncate_mutex in xattr code to serialize
allocations.

CC: Sage Weil 
Reported-by: Fyodor Ustinov 
Signed-off-by: Jan Kara 
Signed-off-by: Greg Kroah-Hartman

NFSv4.1: update nfs4_fattr_bitmap_maxsz

2011-08-08T17:23:07+00:00

commit e5012d1f3861d18c7f3814e757c1c3ab3741dbcd upstream.

Attribute IDs assigned in RFC 5661 now require three bitmaps.
Fixes hitting a BUG_ON in xdr_shrink_bufhead when getting ACLs.

Signed-off-by: Andy Adamson 
Signed-off-by: Trond Myklebust 
Signed-off-by: Greg Kroah-Hartman

mm: prevent concurrent unmap_mapping_range() on the same inode

2011-07-13T03:29:27+00:00

commit 2aa15890f3c191326678f1bd68af61ec6b8753ec upstream.

Michael Leun reported that running parallel opens on a fuse filesystem
can trigger a "kernel BUG at mm/truncate.c:475"

Gurudas Pai reported the same bug on NFS.

The reason is, unmap_mapping_range() is not prepared for more than
one concurrent invocation per inode.  For example:

  thread1: going through a big range, stops in the middle of a vma and
     stores the restart address in vm_truncate_count.

  thread2: comes in with a small (e.g. single page) unmap request on
     the same vma, somewhere before restart_address, finds that the
     vma was already unmapped up to the restart address and happily
     returns without doing anything.

Another scenario would be two big unmap requests, both having to
restart the unmapping and each one setting vm_truncate_count to its
own value.  This could go on forever without any of them being able to
finish.

Truncate and hole punching already serialize with i_mutex.  Other
callers of unmap_mapping_range() do not, and it's difficult to get
i_mutex protection for all callers.  In particular ->d_revalidate(),
which calls invalidate_inode_pages2_range() in fuse, may be called
with or without i_mutex.

This patch adds a new mutex to 'struct address_space' to prevent
running multiple concurrent unmap_mapping_range() on the same mapping.

[ We'll hopefully get rid of all this with the upcoming mm
  preemptibility series by Peter Zijlstra, the "mm: Remove i_mmap_mutex
  lockbreak" patch in particular.  But that is for 2.6.39 ]

Signed-off-by: Miklos Szeredi 
Reported-by: Michael Leun 
Reported-by: Gurudas Pai 
Tested-by: Gurudas Pai 
Acked-by: Hugh Dickins 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

exec: delay address limit change until point of no return

2011-06-23T22:24:09+00:00

commit dac853ae89043f1b7752875300faf614de43c74b upstream.

Unconditionally changing the address limit to USER_DS and not restoring
it to its old value in the error path is wrong because it prevents us
using kernel memory on repeated calls to this function.  This, in fact,
breaks the fallback of hard coded paths to the init program from being
ever successful if the first candidate fails to load.

With this patch applied switching to USER_DS is delayed until the point
of no return is reached which makes it possible to have a multi-arch
rootfs with one arch specific init binary for each of the (hard coded)
probed paths.

Since the address limit is already set to USER_DS when start_thread()
will be invoked, this redundancy can be safely removed.

Signed-off-by: Mathias Krause 
Cc: Al Viro 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

xfs: properly account for reclaimed inodes

2011-06-23T22:24:09+00:00

commit 081003fff467ea0e727f66d5d435b4f473a789b3 upstream.

When marking an inode reclaimable, a per-AG counter is increased, the
inode is tagged reclaimable in its per-AG tree, and, when this is the
first reclaimable inode in the AG, the AG entry in the per-mount tree
is also tagged.

When an inode is finally reclaimed, however, it is only deleted from
the per-AG tree.  Neither the counter is decreased, nor is the parent
tree's AG entry untagged properly.

Since the tags in the per-mount tree are not cleared, the inode
shrinker iterates over all AGs that have had reclaimable inodes at one
point in time.

The counters on the other hand signal an increasing amount of slab
objects to reclaim.  Since "70e60ce xfs: convert inode shrinker to
per-filesystem context" this is not a real issue anymore because the
shrinker bails out after one iteration.

But the problem was observable on a machine running v2.6.34, where the
reclaimable work increased and each process going into direct reclaim
eventually got stuck on the xfs inode shrinking path, trying to scan
several million objects.

Fix this by properly unwinding the reclaimable-state tracking of an
inode when it is reclaimed.

Signed-off-by: Johannes Weiner 
Reviewed-by: Dave Chinner 
Signed-off-by: Alex Elder 
Backported-by: Stefan Priebe 
Signed-off-by: Greg Kroah-Hartman