linux-stable.git/fs, branch v4.13.7

Btrfs: fix overlap of fs_info::flags values

2017-10-12T09:56:17+00:00

commit 69ad59767d094752c23c0fc180a79532fde073d0 upstream.

Because the values of BTRFS_FS_EXCL_OP and BTRFS_FS_QUOTA_OVERRIDE overlap,
we should change the value.

First, BTRFS_FS_EXCL_OP was set to 14.

  commit 171938e52807 ("btrfs: track exclusive filesystem operation in flags")

Next, the value of BTRFS_FS_QUOTA_OVERRIDE was set to 14.

  commit f29efe292198 ("btrfs: add quota override flag to enable quota override for CAP_SYS_RESOURCE")

As a result, the value 14 overlapped, by accident.
This problem is solved by defining the value of BTRFS_FS_EXCL_OP as 16,
the flags are internal.

Fixes: f29efe292198 ("btrfs: add quota override flag to enable quota override for CAP_SYS_RESOURCE")
Signed-off-by: Tsutomu Itoh 
Reviewed-by: David Sterba 
[ minimize the change, update only BTRFS_FS_EXCL_OP ]
Signed-off-by: David Sterba 
Signed-off-by: Greg Kroah-Hartman

btrfs: avoid overflow when sector_t is 32 bit

2017-10-12T09:56:17+00:00

commit 2d8ce70a08fe033c904115d59276ad86adeaa337 upstream.

Jean-Denis Girard noticed commit c821e7f3 "pass bytes to
btrfs_bio_alloc" (https://patchwork.kernel.org/patch/9763081/)
introduces a regression on 32 bit machines.
When CONFIG_LBDAF is _not_ defined (CONFIG_LBDAF == Support for large
(2TB+) block devices and files) sector_t is 32 bit on 32bit machines.

In the function submit_extent_page, 'sector' (which is sector_t type) is
multiplied by 512 to convert it from sectors to bytes, leading to an
overflow when the disk is bigger than 4GB (!).

I added a cast to u64 to avoid overflow.

Fixes: c821e7f3 ("btrfs: pass bytes to btrfs_bio_alloc")
Signed-off-by: Goffredo Baroncelli 
Tested-by: Jean-Denis Girard 
Reviewed-by: David Sterba 
Signed-off-by: David Sterba 
Signed-off-by: Greg Kroah-Hartman

ovl: fix regression caused by exclusive upper/work dir protection

2017-10-12T09:56:16+00:00

commit 85fdee1eef1a9e48ad5716916677e0c5fbc781e3 upstream.

Enforcing exclusive ownership on upper/work dirs caused a docker
regression: https://github.com/moby/moby/issues/34672.

Euan spotted the regression and pointed to the offending commit.
Vivek has brought the regression to my attention and provided this
reproducer:

Terminal 1:

  mount -t overlay -o workdir=work,lowerdir=lower,upperdir=upper none
        merged/

Terminal 2:

  unshare -m

Terminal 1:

  umount merged
  mount -t overlay -o workdir=work,lowerdir=lower,upperdir=upper none
        merged/
  mount: /root/overlay-testing/merged: none already mounted or mount point
         busy

To fix the regression, I replaced the error with an alarming warning.
With index feature enabled, mount does fail, but logs a suggestion to
override exclusive dir protection by disabling index.
Note that index=off mount does take the inuse locks, so a concurrent
index=off will issue the warning and a concurrent index=on mount will fail.

Documentation was updated to reflect this change.

Fixes: 2cac0c00a6cd ("ovl: get exclusive ownership on upper/work dirs")
Reported-by: Euan Kemp 
Reported-by: Vivek Goyal 
Signed-off-by: Amir Goldstein 
Signed-off-by: Miklos Szeredi 
Signed-off-by: Greg Kroah-Hartman

ovl: fix missing unlock_rename() in ovl_do_copy_up()

2017-10-12T09:56:15+00:00

commit 5820dc0888d302ac05f8b91ffdf7e4e53b4fbf53 upstream.

Use the ovl_lock_rename_workdir() helper which requires
unlock_rename() only on lock success.

Fixes: ("fd210b7d67ee ovl: move copy up lock out")
Signed-off-by: Amir Goldstein 
Signed-off-by: Miklos Szeredi 
Signed-off-by: Greg Kroah-Hartman

ovl: fix dentry leak in ovl_indexdir_cleanup()

2017-10-12T09:56:15+00:00

commit dc7ab6773e8171e07f16fd0df0c5eea28c899503 upstream.

index dentry was not released when breaking out of the loop
due to index verification error.

Fixes: 415543d5c64f ("ovl: cleanup bad and stale index entries on mount")
Signed-off-by: Amir Goldstein 
Signed-off-by: Miklos Szeredi 
Signed-off-by: Greg Kroah-Hartman

ovl: fix dput() of ERR_PTR in ovl_cleanup_index()

2017-10-12T09:56:15+00:00

commit 9f4ec904dbd4eb1a2db10d5e7dc16eae386fe64d upstream.

Fixes: caf70cb2ba5d ("ovl: cleanup orphan index entries")
Signed-off-by: Amir Goldstein 
Signed-off-by: Miklos Szeredi 
Signed-off-by: Greg Kroah-Hartman

ovl: fix error value printed in ovl_lookup_index()

2017-10-12T09:56:15+00:00

commit e0082a0f04c432cb6d7128ef60d8e425e45ce025 upstream.

Fixes: 359f392ca53e ("ovl: lookup index entry for copy up origin")
Signed-off-by: Amir Goldstein 
Signed-off-by: Miklos Szeredi 
Signed-off-by: Greg Kroah-Hartman

lsm: fix smack_inode_removexattr and xattr_getsecurity memleak

2017-10-12T09:56:13+00:00

commit 57e7ba04d422c3d41c8426380303ec9b7533ded9 upstream.

security_inode_getsecurity() provides the text string value
of a security attribute. It does not provide a "secctx".
The code in xattr_getsecurity() that calls security_inode_getsecurity()
and then calls security_release_secctx() happened to work because
SElinux and Smack treat the attribute and the secctx the same way.
It fails for cap_inode_getsecurity(), because that module has no
secctx that ever needs releasing. It turns out that Smack is the
one that's doing things wrong by not allocating memory when instructed
to do so by the "alloc" parameter.

The fix is simple enough. Change the security_release_secctx() to
kfree() because it isn't a secctx being returned by
security_inode_getsecurity(). Change Smack to allocate the string when
told to do so.

Note: this also fixes memory leaks for LSMs which implement
inode_getsecurity but not release_secctx, such as capabilities.

Signed-off-by: Casey Schaufler 
Reported-by: Konstantin Khlebnikov 
Signed-off-by: James Morris 
Signed-off-by: Greg Kroah-Hartman

userfaultfd: non-cooperative: fix fork use after free

2017-10-12T09:56:13+00:00

commit 384632e67e0829deb8015ee6ad916b180049d252 upstream.

When reading the event from the uffd, we put it on a temporary
fork_event list to detect if we can still access it after releasing and
retaking the event_wqh.lock.

If fork aborts and removes the event from the fork_event all is fine as
long as we're still in the userfault read context and fork_event head is
still alive.

We've to put the event allocated in the fork kernel stack, back from
fork_event list-head to the event_wqh head, before returning from
userfaultfd_ctx_read, because the fork_event head lifetime is limited to
the userfaultfd_ctx_read stack lifetime.

Forgetting to move the event back to its event_wqh place then results in
__remove_wait_queue(&ctx->event_wqh, &ewq->wq); in
userfaultfd_event_wait_completion to remove it from a head that has been
already freed from the reader stack.

This could only happen if resolve_userfault_fork failed (for example if
there are no file descriptors available to allocate the fork uffd).  If
it succeeded it was put back correctly.

Furthermore, after find_userfault_evt receives a fork event, the forked
userfault context in fork_nctx and uwq->msg.arg.reserved.reserved1 can
be released by the fork thread as soon as the event_wqh.lock is
released.  Taking a reference on the fork_nctx before dropping the lock
prevents an use after free in resolve_userfault_fork().

If the fork side aborted and it already released everything, we still
try to succeed resolve_userfault_fork(), if possible.

Fixes: 893e26e61d04eac9 ("userfaultfd: non-cooperative: Add fork() event")
Link: http://lkml.kernel.org/r/20170920180413.26713-1-aarcange@redhat.com
Signed-off-by: Andrea Arcangeli 
Reported-by: Mark Rutland 
Tested-by: Mark Rutland 
Cc: Pavel Emelyanov 
Cc: Mike Rapoport 
Cc: "Dr. David Alan Gilbert" 
Cc: Mike Kravetz 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

btrfs: prevent to set invalid default subvolid

2017-10-05T07:47:35+00:00

commit 6d6d282932d1a609e60dc4467677e0e863682f57 upstream.

`btrfs sub set-default` succeeds to set an ID which isn't corresponding to any
fs/file tree. If such the bad ID is set to a filesystem, we can't mount this
filesystem without specifying `subvol` or `subvolid` mount options.

Fixes: 6ef5ed0d386b ("Btrfs: add ioctl and incompat flag to set the default mount subvol")
Signed-off-by: Satoru Takeuchi 
Reviewed-by: Qu Wenruo 
Reviewed-by: David Sterba 
Signed-off-by: David Sterba 
Signed-off-by: Greg Kroah-Hartman