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

binfmt_elf: switch to new creds when switching to new mm

2019-05-02T20:42:07+00:00

commit 9f834ec18defc369d73ccf9e87a2790bfa05bf46 upstream.

We used to delay switching to the new credentials until after we had
mapped the executable (and possible elf interpreter).  That was kind of
odd to begin with, since the new executable will actually then _run_
with the new creds, but whatever.

The bigger problem was that we also want to make sure that we turn off
prof events and tracing before we start mapping the new executable
state.  So while this is a cleanup, it's also a fix for a possible
information leak.

Reported-by: Robert Święcki 
Tested-by: Peter Zijlstra 
Acked-by: David Howells 
Acked-by: Oleg Nesterov 
Acked-by: Andy Lutomirski 
Acked-by: Eric W. Biederman 
Cc: Willy Tarreau 
Cc: Kees Cook 
Cc: Al Viro 
Signed-off-by: Linus Torvalds 
Signed-off-by: Ben Hutchings

binfmt_elf: Fix missing SIGKILL for empty PIE

2019-05-02T20:42:06+00:00

Commit ea08dc5191d9 "fs/binfmt_elf.c: fix bug in loading of PIE
binaries", which was a backport of commit a87938b2e246 upstream,
added a new failure path to load_elf_binary().

Before commit 19d860a140be "handle suicide on late failure exits in
execve() in search_binary_handler()", load_elf_binary() wass
responsible for sending a fatal signal to the task in case of an error
after flushing the old executable.  Add that to the new failure path.

Signed-off-by: Ben Hutchings

coredump: fix race condition between mmget_not_zero()/get_task_mm() and core dumping

2019-05-02T20:42:04+00:00

commit 04f5866e41fb70690e28397487d8bd8eea7d712a upstream.

The core dumping code has always run without holding the mmap_sem for
writing, despite that is the only way to ensure that the entire vma
layout will not change from under it.  Only using some signal
serialization on the processes belonging to the mm is not nearly enough.
This was pointed out earlier.  For example in Hugh's post from Jul 2017:

  https://lkml.kernel.org/r/alpine.LSU.2.11.1707191716030.2055@eggly.anvils

  "Not strictly relevant here, but a related note: I was very surprised
   to discover, only quite recently, how handle_mm_fault() may be called
   without down_read(mmap_sem) - when core dumping. That seems a
   misguided optimization to me, which would also be nice to correct"

In particular because the growsdown and growsup can move the
vm_start/vm_end the various loops the core dump does around the vma will
not be consistent if page faults can happen concurrently.

Pretty much all users calling mmget_not_zero()/get_task_mm() and then
taking the mmap_sem had the potential to introduce unexpected side
effects in the core dumping code.

Adding mmap_sem for writing around the ->core_dump invocation is a
viable long term fix, but it requires removing all copy user and page
faults and to replace them with get_dump_page() for all binary formats
which is not suitable as a short term fix.

For the time being this solution manually covers the places that can
confuse the core dump either by altering the vma layout or the vma flags
while it runs.  Once ->core_dump runs under mmap_sem for writing the
function mmget_still_valid() can be dropped.

Allowing mmap_sem protected sections to run in parallel with the
coredump provides some minor parallelism advantage to the swapoff code
(which seems to be safe enough by never mangling any vma field and can
keep doing swapins in parallel to the core dumping) and to some other
corner case.

In order to facilitate the backporting I added "Fixes: 86039bd3b4e6"
however the side effect of this same race condition in /proc/pid/mem
should be reproducible since before 2.6.12-rc2 so I couldn't add any
other "Fixes:" because there's no hash beyond the git genesis commit.

Because find_extend_vma() is the only location outside of the process
context that could modify the "mm" structures under mmap_sem for
reading, by adding the mmget_still_valid() check to it, all other cases
that take the mmap_sem for reading don't need the new check after
mmget_not_zero()/get_task_mm().  The expand_stack() in page fault
context also doesn't need the new check, because all tasks under core
dumping are frozen.

Link: http://lkml.kernel.org/r/20190325224949.11068-1-aarcange@redhat.com
Fixes: 86039bd3b4e6 ("userfaultfd: add new syscall to provide memory externalization")
Signed-off-by: Andrea Arcangeli 
Reported-by: Jann Horn 
Suggested-by: Oleg Nesterov 
Acked-by: Peter Xu 
Reviewed-by: Mike Rapoport 
Reviewed-by: Oleg Nesterov 
Reviewed-by: Jann Horn 
Acked-by: Jason Gunthorpe 
Acked-by: Michal Hocko 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
[bwh: Backported to 3.16:
 - Drop changes in Infiniband and userfaultfd
 - In clear_refs_write(), use up_read() as we never upgrade to a write lock
 - Adjust filename, context]
Signed-off-by: Ben Hutchings

ceph: avoid repeatedly adding inode to mdsc->snap_flush_list

2019-05-02T20:41:57+00:00

commit 04242ff3ac0abbaa4362f97781dac268e6c3541a upstream.

Otherwise, mdsc->snap_flush_list may get corrupted.

Signed-off-by: "Yan, Zheng" 
Reviewed-by: Ilya Dryomov 
Signed-off-by: Ilya Dryomov 
Signed-off-by: Ben Hutchings

fs/dcache: Fix incorrect nr_dentry_unused accounting in shrink_dcache_sb()

2019-05-02T20:41:33+00:00

commit 1dbd449c9943e3145148cc893c2461b72ba6fef0 upstream.

The nr_dentry_unused per-cpu counter tracks dentries in both the LRU
lists and the shrink lists where the DCACHE_LRU_LIST bit is set.

The shrink_dcache_sb() function moves dentries from the LRU list to a
shrink list and subtracts the dentry count from nr_dentry_unused.  This
is incorrect as the nr_dentry_unused count will also be decremented in
shrink_dentry_list() via d_shrink_del().

To fix this double decrement, the decrement in the shrink_dcache_sb()
function is taken out.

Fixes: 4e717f5c1083 ("list_lru: remove special case function list_lru_dispose_all."
Signed-off-by: Waiman Long 
Reviewed-by: Dave Chinner 
Signed-off-by: Linus Torvalds 
Signed-off-by: Ben Hutchings

CIFS: Do not consider -ENODATA as stat failure for reads

2019-05-02T20:41:32+00:00

commit 082aaa8700415f6471ec9c5ef0c8307ca214989a upstream.

When doing reads beyound the end of a file the server returns
error STATUS_END_OF_FILE error which is mapped to -ENODATA.
Currently we report it as a failure which confuses read stats.
Change it to not consider -ENODATA as failure for stat purposes.

Signed-off-by: Pavel Shilovsky 
Signed-off-by: Steve French 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

CIFS: Do not count -ENODATA as failure for query directory

2019-05-02T20:41:31+00:00

commit 8e6e72aeceaaed5aeeb1cb43d3085de7ceb14f79 upstream.

Signed-off-by: Pavel Shilovsky 
Signed-off-by: Steve French 
Signed-off-by: Ben Hutchings

debugfs: fix debugfs_rename parameter checking

2019-05-02T20:41:29+00:00

commit d88c93f090f708c18195553b352b9f205e65418f upstream.

debugfs_rename() needs to check that the dentries passed into it really
are valid, as sometimes they are not (i.e. if the return value of
another debugfs call is passed into this one.)  So fix this up by
properly checking if the two parent directories are errors (they are
allowed to be NULL), and if the dentry to rename is not NULL or an
error.

Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

fuse: decrement NR_WRITEBACK_TEMP on the right page

2019-05-02T20:41:23+00:00

commit a2ebba824106dabe79937a9f29a875f837e1b6d4 upstream.

NR_WRITEBACK_TEMP is accounted on the temporary page in the request, not
the page cache page.

Fixes: 8b284dc47291 ("fuse: writepages: handle same page rewrites")
Signed-off-by: Miklos Szeredi 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

fuse: call pipe_buf_release() under pipe lock

2019-05-02T20:41:22+00:00

commit 9509941e9c534920ccc4771ae70bd6cbbe79df1c upstream.

Some of the pipe_buf_release() handlers seem to assume that the pipe is
locked - in particular, anon_pipe_buf_release() accesses pipe->tmp_page
without taking any extra locks. From a glance through the callers of
pipe_buf_release(), it looks like FUSE is the only one that calls
pipe_buf_release() without having the pipe locked.

This bug should only lead to a memory leak, nothing terrible.

Fixes: dd3bb14f44a6 ("fuse: support splice() writing to fuse device")
Signed-off-by: Jann Horn 
Signed-off-by: Miklos Szeredi 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings