linux-stable.git/fs, branch v3.18.17

efivarfs: Ensure VariableName is NUL-terminated

2015-06-28T17:39:26+00:00

[ Upstream commit c57dcb566d3d866a302a1da2e06344bec31d5bcd ]

Some buggy firmware implementations update VariableNameSize on success
such that it does not include the final NUL character which results in
garbage in the efivarfs name entries.  Use kzalloc on the efivar_entry
(as is done in efivars.c) to ensure that the name is always
NUL-terminated.

The buggy firmware is:
BIOS Information
        Vendor: Intel Corp.
        Version: S1200RP.86B.02.02.0005.102320140911
        Release Date: 10/23/2014
        BIOS Revision: 4.6
System Information
        Manufacturer: Intel Corporation
        Product Name: S1200RP_SE

Signed-off-by: Ross Lagerwall 
Acked-by: Matthew Garrett 
Cc: Jeremy Kerr 
Cc: 
Signed-off-by: Matt Fleming 
Signed-off-by: Sasha Levin

mnt: Fix the error check in __detach_mounts

2015-06-28T17:39:24+00:00

[ Upstream commit f53e57975151f54ad8caa1b0ac8a78091cd5700a ]

lookup_mountpoint can return either NULL or an error value.
Update the test in __detach_mounts to test for an error value
to avoid pathological cases causing a NULL pointer dereferences.

The callers of __detach_mounts should prevent it from ever being
called on an unlinked dentry but don't take any chances.

Cc: stable@vger.kernel.org
Signed-off-by: "Eric W. Biederman" 
Signed-off-by: Sasha Levin

ext4: fix bh leak on error paths in ext4_rename() and ext4_cross_rename()

2015-06-28T17:39:22+00:00

[ Upstream commit 7071b715873a66b69a9c0c5839963bb51aeae41b ]

Release references to buffer-heads if ext4_journal_start() fails.

Fixes: 5b61de757535 ("ext4: start handle at least possible moment when renaming files")
Signed-off-by: Konstantin Khlebnikov 
Signed-off-by: Theodore Ts'o 
Reviewed-by: Jan Kara 
Signed-off-by: Sasha Levin

fs/binfmt_elf.c:load_elf_binary(): return -EINVAL on zero-length mappings

2015-06-15T18:00:57+00:00

[ Upstream commit 073aba98f6a2235e2ac4a8402b1a131ab032876e ]

commit 2b1d3ae940acd11be44c6eced5873d47c2e00ffa upstream.

load_elf_binary() returns `retval', not `error'.

Fixes: a87938b2e246b81b4fb ("fs/binfmt_elf.c: fix bug in loading of PIE binaries")
Reported-by: James Hogan 
Cc: Michael Davidson 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

vfs: read file_handle only once in handle_to_path

2015-06-10T17:42:44+00:00

[ Upstream commit 161f873b89136eb1e69477c847d5a5033239d9ba ]

We used to read file_handle twice.  Once to get the amount of extra
bytes, and once to fetch the entire structure.

This may be problematic since we do size verifications only after the
first read, so if the number of extra bytes changes in userspace between
the first and second calls, we'll have an incoherent view of
file_handle.

Instead, read the constant size once, and copy that over to the final
structure without having to re-read it again.

Signed-off-by: Sasha Levin 
Cc: Al Viro 
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

nfsd: fix the check for confirmed openowner in nfs4_preprocess_stateid_op

2015-06-10T17:42:35+00:00

[ Upstream commit ebe9cb3bb13e7b9b281969cd279ce70834f7500f ]

If we find a non-confirmed openowner we jump to exit the function, but do
not set an error value.  Fix this by factoring out a helper to do the
check and properly set the error from nfsd4_validate_stateid.

Cc: stable@vger.kernel.org
Signed-off-by: Christoph Hellwig 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Sasha Levin

parisc,metag: Fix crashes due to stack randomization on stack-grows-upwards architectures

2015-06-10T17:42:33+00:00

[ Upstream commit d045c77c1a69703143a36169c224429c48b9eecd ]

On architectures where the stack grows upwards (CONFIG_STACK_GROWSUP=y,
currently parisc and metag only) stack randomization sometimes leads to crashes
when the stack ulimit is set to lower values than STACK_RND_MASK (which is 8 MB
by default if not defined in arch-specific headers).

The problem is, that when the stack vm_area_struct is set up in fs/exec.c, the
additional space needed for the stack randomization (as defined by the value of
STACK_RND_MASK) was not taken into account yet and as such, when the stack
randomization code added a random offset to the stack start, the stack
effectively got smaller than what the user defined via rlimit_max(RLIMIT_STACK)
which then sometimes leads to out-of-stack situations and crashes.

This patch fixes it by adding the maximum possible amount of memory (based on
STACK_RND_MASK) which theoretically could be added by the stack randomization
code to the initial stack size. That way, the user-defined stack size is always
guaranteed to be at minimum what is defined via rlimit_max(RLIMIT_STACK).

This bug is currently not visible on the metag architecture, because on metag
STACK_RND_MASK is defined to 0 which effectively disables stack randomization.

The changes to fs/exec.c are inside an "#ifdef CONFIG_STACK_GROWSUP"
section, so it does not affect other platformws beside those where the
stack grows upwards (parisc and metag).

Signed-off-by: Helge Deller 
Cc: linux-parisc@vger.kernel.org
Cc: James Hogan 
Cc: linux-metag@vger.kernel.org
Cc: stable@vger.kernel.org # v3.16+
Signed-off-by: Sasha Levin

jbd2: fix r_count overflows leading to buffer overflow in journal recovery

2015-06-10T17:42:24+00:00

[ Upstream commit e531d0bceb402e643a4499de40dd3fa39d8d2e43 ]

The journal revoke block recovery code does not check r_count for
sanity, which means that an evil value of r_count could result in
the kernel reading off the end of the revoke table and into whatever
garbage lies beyond.  This could crash the kernel, so fix that.

However, in testing this fix, I discovered that the code to write
out the revoke tables also was not correctly checking to see if the
block was full -- the current offset check is fine so long as the
revoke table space size is a multiple of the record size, but this
is not true when either journal_csum_v[23] are set.

Signed-off-by: Darrick J. Wong 
Signed-off-by: Theodore Ts'o 
Reviewed-by: Jan Kara 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

ext4: check for zero length extent explicitly

2015-06-10T17:42:24+00:00

[ Upstream commit 2f974865ffdfe7b9f46a9940836c8b167342563d ]

The following commit introduced a bug when checking for zero length extent

5946d08 ext4: check for overlapping extents in ext4_valid_extent_entries()

Zero length extent could pass the check if lblock is zero.

Adding the explicit check for zero length back.

Signed-off-by: Eryu Guan 
Signed-off-by: Theodore Ts'o 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

ext4: fix NULL pointer dereference when journal restart fails

2015-06-10T17:42:23+00:00

[ Upstream commit 9d506594069355d1fb2de3f9104667312ff08ed3 ]

Currently when journal restart fails, we'll have the h_transaction of
the handle set to NULL to indicate that the handle has been effectively
aborted. We handle this situation quietly in the jbd2_journal_stop() and just
free the handle and exit because everything else has been done before we
attempted (and failed) to restart the journal.

Unfortunately there are a number of problems with that approach
introduced with commit

41a5b913197c "jbd2: invalidate handle if jbd2_journal_restart()
fails"

First of all in ext4 jbd2_journal_stop() will be called through
__ext4_journal_stop() where we would try to get a hold of the superblock
by dereferencing h_transaction which in this case would lead to NULL
pointer dereference and crash.

In addition we're going to free the handle regardless of the refcount
which is bad as well, because others up the call chain will still
reference the handle so we might potentially reference already freed
memory.

Moreover it's expected that we'll get aborted handle as well as detached
handle in some of the journalling function as the error propagates up
the stack, so it's unnecessary to call WARN_ON every time we get
detached handle.

And finally we might leak some memory by forgetting to free reserved
handle in jbd2_journal_stop() in the case where handle was detached from
the transaction (h_transaction is NULL).

Fix the NULL pointer dereference in __ext4_journal_stop() by just
calling jbd2_journal_stop() quietly as suggested by Jan Kara. Also fix
the potential memory leak in jbd2_journal_stop() and use proper
handle refcounting before we attempt to free it to avoid use-after-free
issues.

And finally remove all WARN_ON(!transaction) from the code so that we do
not get random traces when something goes wrong because when journal
restart fails we will get to some of those functions.

Cc: stable@vger.kernel.org
Signed-off-by: Lukas Czerner 
Signed-off-by: Theodore Ts'o 
Reviewed-by: Jan Kara 
Signed-off-by: Sasha Levin