linux-toradex.git/fs, branch v3.2.34

eCryptfs: check for eCryptfs cipher support at mount

2012-11-16T16:47:19+00:00

commit 5f5b331d5c21228a6519dcb793fc1629646c51a6 upstream.

The issue occurs when eCryptfs is mounted with a cipher supported by
the crypto subsystem but not by eCryptfs. The mount succeeds and an
error does not occur until a write. This change checks for eCryptfs
cipher support at mount time.

Resolves Launchpad issue #338914, reported by Tyler Hicks in 03/2009.
https://bugs.launchpad.net/ecryptfs/+bug/338914

Signed-off-by: Tim Sally 
Signed-off-by: Tyler Hicks 
Signed-off-by: Ben Hutchings

eCryptfs: Copy up POSIX ACL and read-only flags from lower mount

2012-11-16T16:47:18+00:00

commit 069ddcda37b2cf5bb4b6031a944c0e9359213262 upstream.

When the eCryptfs mount options do not include '-o acl', but the lower
filesystem's mount options do include 'acl', the MS_POSIXACL flag is not
flipped on in the eCryptfs super block flags. This flag is what the VFS
checks in do_last() when deciding if the current umask should be applied
to a newly created inode's mode or not. When a default POSIX ACL mask is
set on a directory, the current umask is incorrectly applied to new
inodes created in the directory. This patch ignores the MS_POSIXACL flag
passed into ecryptfs_mount() and sets the flag on the eCryptfs super
block depending on the flag's presence on the lower super block.

Additionally, it is incorrect to allow a writeable eCryptfs mount on top
of a read-only lower mount. This missing check did not allow writes to
the read-only lower mount because permissions checks are still performed
on the lower filesystem's objects but it is best to simply not allow a
rw mount on top of ro mount. However, a ro eCryptfs mount on top of a rw
mount is valid and still allowed.

https://launchpad.net/bugs/1009207

Signed-off-by: Tyler Hicks 
Reported-by: Stefan Beller 
Cc: John Johansen 
Signed-off-by: Ben Hutchings

fanotify: fix missing break

2012-11-16T16:47:12+00:00

commit 848561d368751a1c0f679b9f045a02944506a801 upstream.

Anders Blomdell noted in 2010 that Fanotify lost events and provided a
test case.  Eric Paris confirmed it was a bug and posted a fix to the
list

  https://groups.google.com/forum/?fromgroups=#!topic/linux.kernel/RrJfTfyW2BE

but never applied it.  Repeated attempts over time to actually get him
to apply it have never had a reply from anyone who has raised it

So apply it anyway

Signed-off-by: Alan Cox 
Reported-by: Anders Blomdell 
Cc: Eric Paris 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Ben Hutchings

xfs: fix reading of wrapped log data

2012-11-16T16:47:12+00:00

commit 6ce377afd1755eae5c93410ca9a1121dfead7b87 upstream.

Commit 4439647 ("xfs: reset buffer pointers before freeing them") in
3.0-rc1 introduced a regression when recovering log buffers that
wrapped around the end of log. The second part of the log buffer at
the start of the physical log was being read into the header buffer
rather than the data buffer, and hence recovery was seeing garbage
in the data buffer when it got to the region of the log buffer that
was incorrectly read.

Reported-by: Torsten Kaiser 
Signed-off-by: Dave Chinner 
Reviewed-by: Christoph Hellwig 
Reviewed-by: Mark Tinguely 
Signed-off-by: Ben Myers 
Signed-off-by: Ben Hutchings

cifs: fix potential buffer overrun in cifs.idmap handling code

2012-11-16T16:47:07+00:00

commit 36960e440ccf94349c09fb944930d3bfe4bc473f upstream.

The userspace cifs.idmap program generally works with the wbclient libs
to generate binary SIDs in userspace. That program defines the struct
that holds these values as having a max of 15 subauthorities. The kernel
idmapping code however limits that value to 5.

When the kernel copies those values around though, it doesn't sanity
check the num_subauths value handed back from userspace or from the
server. It's possible therefore for userspace to hand us back a bogus
num_subauths value (or one that's valid, but greater than 5) that could
cause the kernel to walk off the end of the cifs_sid->sub_auths array.

Fix this by defining a new routine for copying sids and using that in
all of the places that copy it. If we end up with a sid that's longer
than expected then this approach will just lop off the "extra" subauths,
but that's basically what the code does today already. Better approaches
might be to fix this code to reject SIDs with >5 subauths, or fix it
to handle the subauths array dynamically.

At the same time, change the kernel to check the length of the data
returned by userspace. If it's shorter than struct cifs_sid, reject it
and return -EIO. If that happens we'll end up with fields that are
basically uninitialized.

Long term, it might make sense to redefine cifs_sid using a flexarray at
the end, to allow for variable-length subauth lists, and teach the code
to handle the case where the subauths array being passed in from
userspace is shorter than 5 elements.

Note too, that I don't consider this a security issue since you'd need
a compromised cifs.idmap program. If you have that, you can do all sorts
of nefarious stuff. Still, this is probably reasonable for stable.

Reviewed-by: Shirish Pargaonkar 
Signed-off-by: Jeff Layton 
Signed-off-by: Ben Hutchings

nfs: Show original device name verbatim in /proc/*/mount{s,info}

2012-11-16T16:47:05+00:00

commit 97a54868262da1629a3e65121e65b8e8c4419d9f upstream.

Since commit c7f404b ('vfs: new superblock methods to override
/proc/*/mount{s,info}'), nfs_path() is used to generate the mounted
device name reported back to userland.

nfs_path() always generates a trailing slash when the given dentry is
the root of an NFS mount, but userland may expect the original device
name to be returned verbatim (as it used to be).  Make this
canonicalisation optional and change the callers accordingly.

[jrnieder@gmail.com: use flag instead of bool argument]
Reported-and-tested-by: Chris Hiestand 
Reference: http://bugs.debian.org/669314
Signed-off-by: Ben Hutchings 
Signed-off-by: Jonathan Nieder 
Signed-off-by: Trond Myklebust 
[bwh: Backported to 3.2:
 - Adjust context
 - nfs_show_devname() still takes a pointer to struct vfsmount]

nfsv3: Make v3 mounts fail with ETIMEDOUTs instead EIO on mountd timeouts

2012-11-16T16:47:05+00:00

commit acce94e68a0f346115fd41cdc298197d2d5a59ad upstream.

In very busy v3 environment, rpc.mountd can respond to the NULL
procedure but not the MNT procedure in a timely manner causing
the MNT procedure to time out. The problem is the mount system
call returns EIO which causes the mount to fail, instead of
ETIMEDOUT, which would cause the mount to be retried.

This patch sets the RPC_TASK_SOFT|RPC_TASK_TIMEOUT flags to
the rpc_call_sync() call in nfs_mount() which causes
ETIMEDOUT to be returned on timed out connections.

Signed-off-by: Steve Dickson 
Signed-off-by: Trond Myklebust 
Signed-off-by: Ben Hutchings

NFS: fix bug in legacy DNS resolver.

2012-11-16T16:47:04+00:00

commit 8d96b10639fb402357b75b055b1e82a65ff95050 upstream.

The DNS resolver's use of the sunrpc cache involves a 'ttl' number
(relative) rather that a timeout (absolute).  This confused me when
I wrote
  commit c5b29f885afe890f953f7f23424045cdad31d3e4
     "sunrpc: use seconds since boot in expiry cache"

and I managed to break it.  The effect is that any TTL is interpreted
as 0, and nothing useful gets into the cache.

This patch removes the use of get_expiry() - which really expects an
expiry time - and uses get_uint() instead, treating the int correctly
as a ttl.

This fixes a regression that has been present since 2.6.37, causing
certain NFS accesses in certain environments to incorrectly fail.

Reported-by: Chuck Lever 
Tested-by: Chuck Lever 
Signed-off-by: NeilBrown 
Signed-off-by: Trond Myklebust 
Signed-off-by: Ben Hutchings

NFSv4: nfs4_locku_done must release the sequence id

2012-11-16T16:47:04+00:00

commit 2b1bc308f492589f7d49012ed24561534ea2be8c upstream.

If the state recovery machinery is triggered by the call to
nfs4_async_handle_error() then we can deadlock.

Signed-off-by: Trond Myklebust 
Signed-off-by: Ben Hutchings

NFSv4.1: We must release the sequence id when we fail to get a session slot

2012-11-16T16:47:04+00:00

commit 2240a9e2d013d8269ea425b73e1d7a54c7bc141f upstream.

If we do not release the sequence id in cases where we fail to get a
session slot, then we can deadlock if we hit a recovery scenario.

Signed-off-by: Trond Myklebust 
[bwh: Backported to 3.2:
 - Adjust context
 - nfs4_setup_sequence() has an additional 'cache_reply' parameter]
Signed-off-by: Ben Hutchings