linux-toradex.git/fs, branch v4.9.30

nfsd: encoders mustn't use unitialized values in error cases

2017-05-25T13:44:49+00:00

commit f961e3f2acae94b727380c0b74e2d3954d0edf79 upstream.

In error cases, lgp->lg_layout_type may be out of bounds; so we
shouldn't be using it until after the check of nfserr.

This was seen to crash nfsd threads when the server receives a LAYOUTGET
request with a large layout type.

GETDEVICEINFO has the same problem.

Reported-by: Ari Kauppi 
Reviewed-by: Christoph Hellwig 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Greg Kroah-Hartman

nfsd: fix undefined behavior in nfsd4_layout_verify

2017-05-25T13:44:48+00:00

commit b550a32e60a4941994b437a8d662432a486235a5 upstream.

  UBSAN: Undefined behaviour in fs/nfsd/nfs4proc.c:1262:34
  shift exponent 128 is too large for 32-bit type 'int'

Depending on compiler+architecture, this may cause the check for
layout_type to succeed for overly large values (which seems to be the
case with amd64). The large value will be later used in de-referencing
nfsd4_layout_ops for function pointers.

Reported-by: Jani Tuovila 
Signed-off-by: Ari Kauppi 
[colin.king@canonical.com: use LAYOUT_TYPE_MAX instead of 32]
Reviewed-by: Dan Carpenter 
Reviewed-by: Christoph Hellwig 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Greg Kroah-Hartman

NFS: Use GFP_NOIO for two allocations in writeback

2017-05-25T13:44:48+00:00

commit ae97aa524ef495b6276fd26f5d5449fb22975d7c upstream.

Prevent a deadlock that can occur if we wait on allocations
that try to write back our pages.

Signed-off-by: Benjamin Coddington 
Fixes: 00bfa30abe869 ("NFS: Create a common pgio_alloc and pgio_release...")
Signed-off-by: Trond Myklebust 
Signed-off-by: Greg Kroah-Hartman

NFS: Fix use after free in write error path

2017-05-25T13:44:48+00:00

commit 1f84ccdf37d0db3a70714d02d51b0b6d45887fb8 upstream.

Signed-off-by: Fred Isaman 
Fixes: 0bcbf039f6b2b ("nfs: handle request add failure properly")
Signed-off-by: Trond Myklebust 
Signed-off-by: Greg Kroah-Hartman

NFSv4: Fix a hang in OPEN related to server reboot

2017-05-25T13:44:48+00:00

commit 56e0d71ef12f026d96213e45a662bde6bbff4676 upstream.

If the server fails to return the attributes as part of an OPEN
reply, and then reboots, we can end up hanging. The reason is that
the client attempts to send a GETATTR in order to pick up the
missing OPEN call, but fails to release the slot first, causing
reboot recovery to deadlock.

Signed-off-by: Trond Myklebust 
Fixes: 2e80dbe7ac51a ("NFSv4.1: Close callback races for OPEN, LAYOUTGET...")
Signed-off-by: Greg Kroah-Hartman

fscrypt: avoid collisions when presenting long encrypted filenames

2017-05-25T13:44:38+00:00

commit 6b06cdee81d68a8a829ad8e8d0f31d6836744af9 upstream.

When accessing an encrypted directory without the key, userspace must
operate on filenames derived from the ciphertext names, which contain
arbitrary bytes.  Since we must support filenames as long as NAME_MAX,
we can't always just base64-encode the ciphertext, since that may make
it too long.  Currently, this is solved by presenting long names in an
abbreviated form containing any needed filesystem-specific hashes (e.g.
to identify a directory block), then the last 16 bytes of ciphertext.
This needs to be sufficient to identify the actual name on lookup.

However, there is a bug.  It seems to have been assumed that due to the
use of a CBC (ciphertext block chaining)-based encryption mode, the last
16 bytes (i.e. the AES block size) of ciphertext would depend on the
full plaintext, preventing collisions.  However, we actually use CBC
with ciphertext stealing (CTS), which handles the last two blocks
specially, causing them to appear "flipped".  Thus, it's actually the
second-to-last block which depends on the full plaintext.

This caused long filenames that differ only near the end of their
plaintexts to, when observed without the key, point to the wrong inode
and be undeletable.  For example, with ext4:

    # echo pass | e4crypt add_key -p 16 edir/
    # seq -f "edir/abcdefghijklmnopqrstuvwxyz012345%.0f" 100000 | xargs touch
    # find edir/ -type f | xargs stat -c %i | sort | uniq | wc -l
    100000
    # sync
    # echo 3 > /proc/sys/vm/drop_caches
    # keyctl new_session
    # find edir/ -type f | xargs stat -c %i | sort | uniq | wc -l
    2004
    # rm -rf edir/
    rm: cannot remove 'edir/_A7nNFi3rhkEQlJ6P,hdzluhODKOeWx5V': Structure needs cleaning
    ...

To fix this, when presenting long encrypted filenames, encode the
second-to-last block of ciphertext rather than the last 16 bytes.

Although it would be nice to solve this without depending on a specific
encryption mode, that would mean doing a cryptographic hash like SHA-256
which would be much less efficient.  This way is sufficient for now, and
it's still compatible with encryption modes like HEH which are strong
pseudorandom permutations.  Also, changing the presented names is still
allowed at any time because they are only provided to allow applications
to do things like delete encrypted directories.  They're not designed to
be used to persistently identify files --- which would be hard to do
anyway, given that they're encrypted after all.

For ease of backports, this patch only makes the minimal fix to both
ext4 and f2fs.  It leaves ubifs as-is, since ubifs doesn't compare the
ciphertext block yet.  Follow-on patches will clean things up properly
and make the filesystems use a shared helper function.

Fixes: 5de0b4d0cd15 ("ext4 crypto: simplify and speed up filename encryption")
Reported-by: Gwendal Grignou 
Signed-off-by: Eric Biggers 
Signed-off-by: Theodore Ts'o 
Signed-off-by: Greg Kroah-Hartman

f2fs: check entire encrypted bigname when finding a dentry

2017-05-25T13:44:38+00:00

commit 6332cd32c8290a80e929fc044dc5bdba77396e33 upstream.

If user has no key under an encrypted dir, fscrypt gives digested dentries.
Previously, when looking up a dentry, f2fs only checks its hash value with
first 4 bytes of the digested dentry, which didn't handle hash collisions fully.
This patch enhances to check entire dentry bytes likewise ext4.

Eric reported how to reproduce this issue by:

 # seq -f "edir/abcdefghijklmnopqrstuvwxyz012345%.0f" 100000 | xargs touch
 # find edir -type f | xargs stat -c %i | sort | uniq | wc -l
100000
 # sync
 # echo 3 > /proc/sys/vm/drop_caches
 # keyctl new_session
 # find edir -type f | xargs stat -c %i | sort | uniq | wc -l
99999

Cc: 
Reported-by: Eric Biggers 
Signed-off-by: Jaegeuk Kim 
(fixed f2fs_dentry_hash() to work even when the hash is 0)
Signed-off-by: Eric Biggers 
Signed-off-by: Theodore Ts'o 
Signed-off-by: Greg Kroah-Hartman

proc: Fix unbalanced hard link numbers

2017-05-25T13:44:37+00:00

commit d66bb1607e2d8d384e53f3d93db5c18483c8c4f7 upstream.

proc_create_mount_point() forgot to increase the parent's nlink, and
it resulted in unbalanced hard link numbers, e.g. /proc/fs shows one
less than expected.

Fixes: eb6d38d5427b ("proc: Allow creating permanently empty directories...")
Reported-by: Tristan Ye 
Signed-off-by: Takashi Iwai 
Signed-off-by: Eric W. Biederman 
Signed-off-by: Greg Kroah-Hartman

fanotify: don't expose EOPENSTALE to userspace

2017-05-25T13:44:31+00:00

commit 4ff33aafd32e084f5ee7faa54ba06e95f8b1b8af upstream.

When delivering an event to userspace for a file on an NFS share,
if the file is deleted on server side before user reads the event,
user will not get the event.

If the event queue contained several events, the stale event is
quietly dropped and read() returns to user with events read so far
in the buffer.

If the event queue contains a single stale event or if the stale
event is a permission event, read() returns to user with the kernel
internal error code 518 (EOPENSTALE), which is not a POSIX error code.

Check the internal return value -EOPENSTALE in fanotify_read(), just
the same as it is checked in path_openat() and drop the event in the
cases that it is not already dropped.

This is a reproducer from Marko Rauhamaa:

Just take the example program listed under "man fanotify" ("fantest")
and follow these steps:

    ==============================================================
    NFS Server    NFS Client(1)     NFS Client(2)
    ==============================================================
    # echo foo >/nfsshare/bar.txt
                  # cat /nfsshare/bar.txt
                  foo
                                    # ./fantest /nfsshare
                                    Press enter key to terminate.
                                    Listening for events.
    # rm -f /nfsshare/bar.txt
                  # cat /nfsshare/bar.txt
                                    read: Unknown error 518
                  cat: /nfsshare/bar.txt: Operation not permitted
    ==============================================================

where NFS Client (1) and (2) are two terminal sessions on a single NFS
Client machine.

Reported-by: Marko Rauhamaa 
Tested-by: Marko Rauhamaa 
Cc: 
Signed-off-by: Amir Goldstein 
Signed-off-by: Jan Kara 
Signed-off-by: Greg Kroah-Hartman

pstore: Shut down worker when unregistering

2017-05-20T12:28:42+00:00

commit 6330d5534786d5315d56d558aa6d20740f97d80a upstream.

When built as a module and running with update_ms >= 0, pstore will Oops
during module unload since the work timer is still running. This makes sure
the worker is stopped before unloading.

Signed-off-by: Kees Cook 
Signed-off-by: Greg Kroah-Hartman