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

fscrypto: only allow setting encryption policy on directories

2016-09-15T06:20:29+00:00

commit 002ced4be6429918800ce3e41d5cbc2d7c01822c upstream.

The FS_IOC_SET_ENCRYPTION_POLICY ioctl allowed setting an encryption
policy on nondirectory files.  This was unintentional, and in the case
of nonempty regular files did not behave as expected because existing
data was not actually encrypted by the ioctl.

In the case of ext4, the user could also trigger filesystem errors in
->empty_dir(), e.g. due to mismatched "directory" checksums when the
kernel incorrectly tried to interpret a regular file as a directory.

This bug affected ext4 with kernels v4.8-rc1 or later and f2fs with
kernels v4.6 and later.  It appears that older kernels only permitted
directories and that the check was accidentally lost during the
refactoring to share the file encryption code between ext4 and f2fs.

This patch restores the !S_ISDIR() check that was present in older
kernels.

Signed-off-by: Eric Biggers 
Signed-off-by: Theodore Ts'o 
Signed-off-by: Greg Kroah-Hartman

fscrypto: add authorization check for setting encryption policy

2016-09-15T06:20:29+00:00

commit 163ae1c6ad6299b19e22b4a35d5ab24a89791a98 upstream.

On an ext4 or f2fs filesystem with file encryption supported, a user
could set an encryption policy on any empty directory(*) to which they
had readonly access.  This is obviously problematic, since such a
directory might be owned by another user and the new encryption policy
would prevent that other user from creating files in their own directory
(for example).

Fix this by requiring inode_owner_or_capable() permission to set an
encryption policy.  This means that either the caller must own the file,
or the caller must have the capability CAP_FOWNER.

(*) Or also on any regular file, for f2fs v4.6 and later and ext4
    v4.8-rc1 and later; a separate bug fix is coming for that.

Signed-off-by: Eric Biggers 
Signed-off-by: Theodore Ts'o 
Signed-off-by: Greg Kroah-Hartman

bdev: fix NULL pointer dereference

2016-09-15T06:20:28+00:00

commit e9e5e3fae8da7e237049e00e0bfc9e32fd808fe8 upstream.

I got this:

    kasan: GPF could be caused by NULL-ptr deref or user memory access
    general protection fault: 0000 [#1] PREEMPT SMP KASAN
    Dumping ftrace buffer:
       (ftrace buffer empty)
    CPU: 0 PID: 5505 Comm: syz-executor Not tainted 4.8.0-rc2+ #161
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014
    task: ffff880113415940 task.stack: ffff880118350000
    RIP: 0010:[]  [] bd_mount+0x52/0xa0
    RSP: 0018:ffff880118357ca0  EFLAGS: 00010207
    RAX: dffffc0000000000 RBX: ffffffffffffffff RCX: ffffc90000bb6000
    RDX: 0000000000000018 RSI: ffffffff846d6b20 RDI: 00000000000000c7
    RBP: ffff880118357cb0 R08: ffff880115967c68 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000000 R12: ffff8801188211e8
    R13: ffffffff847baa20 R14: ffff8801139cb000 R15: 0000000000000080
    FS:  00007fa3ff6c0700(0000) GS:ffff88011aa00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007fc1d8cc7e78 CR3: 0000000109f20000 CR4: 00000000000006f0
    DR0: 000000000000001e DR1: 000000000000001e DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600
    Stack:
     ffff880112cfd6c0 ffff8801188211e8 ffff880118357cf0 ffffffff8167f207
     ffffffff816d7a1e ffff880112a413c0 ffffffff847baa20 ffff8801188211e8
     0000000000000080 ffff880112cfd6c0 ffff880118357d38 ffffffff816dce0a
    Call Trace:
     [] mount_fs+0x97/0x2e0
     [] ? alloc_vfsmnt+0x55e/0x760
     [] vfs_kern_mount+0x7a/0x300
     [] ? _raw_read_unlock+0x2c/0x50
     [] do_mount+0x3d7/0x2730
     [] ? trace_do_page_fault+0x1f4/0x3a0
     [] ? copy_mount_string+0x40/0x40
     [] ? memset+0x31/0x40
     [] ? copy_mount_options+0x1ee/0x320
     [] SyS_mount+0xb2/0x120
     [] ? copy_mnt_ns+0x970/0x970
     [] do_syscall_64+0x1c4/0x4e0
     [] entry_SYSCALL64_slow_path+0x25/0x25
    Code: 83 e8 63 1b fc ff 48 85 c0 48 89 c3 74 4c e8 56 35 d1 ff 48 8d bb c8 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 75 36 4c 8b a3 c8 00 00 00 48 b8 00 00 00 00 00 fc
    RIP  [] bd_mount+0x52/0xa0
     RSP 
    ---[ end trace 13690ad962168b98 ]---

mount_pseudo() returns ERR_PTR(), not NULL, on error.

Fixes: 3684aa7099e0 ("block-dev: enable writeback cgroup support")
Cc: Shaohua Li 
Cc: Tejun Heo 
Cc: Jens Axboe 
Signed-off-by: Vegard Nossum 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

ubifs: Fix assertion in layout_in_gaps()

2016-09-15T06:20:28+00:00

commit c0082e985fdf77b02fc9e0dac3b58504dcf11b7a upstream.

An assertion in layout_in_gaps() verifies that the gap_lebs pointer is
below the maximum bound. When computing this maximum bound the idx_lebs
count is multiplied by sizeof(int), while C pointers arithmetic does take
into account the size of the pointed elements implicitly already. Remove
the multiplication to fix the assertion.

Fixes: 1e51764a3c2ac05a ("UBIFS: add new flash file system")
Signed-off-by: Vincent Stehlé 
Cc: Artem Bityutskiy 
Signed-off-by: Artem Bityutskiy 
Signed-off-by: Richard Weinberger 
Signed-off-by: Greg Kroah-Hartman

ubifs: Fix xattr generic handler usage

2016-09-15T06:20:28+00:00

commit 17ce1eb0b64eb27d4f9180daae7495fa022c7b0d upstream.

UBIFS uses full names to work with xattrs, therefore we have to use
xattr_full_name() to obtain the xattr prefix as string.

Cc: Andreas Gruenbacher 
Fixes: 2b88fc21ca ("ubifs: Switch to generic xattr handlers")
Signed-off-by: Richard Weinberger 
Reviewed-by: Andreas Gruenbacher 
Tested-by: Dongsheng Yang 
Signed-off-by: Greg Kroah-Hartman

ovl: fix workdir creation

2016-09-15T06:20:28+00:00

commit e1ff3dd1ae52cef5b5373c8cc4ad949c2c25a71c upstream.

Workdir creation fails in latest kernel.

Fix by allowing EOPNOTSUPP as a valid return value from
vfs_removexattr(XATTR_NAME_POSIX_ACL_*).  Upper filesystem may not support
ACL and still be perfectly able to support overlayfs.

Reported-by: Martin Ziegler 
Signed-off-by: Miklos Szeredi 
Fixes: c11b9fdd6a61 ("ovl: remove posix_acl_default from workdir")
Signed-off-by: Greg Kroah-Hartman

ovl: listxattr: use strnlen()

2016-09-15T06:20:28+00:00

commit 7cb35119d067191ce9ebc380a599db0b03cbd9d9 upstream.

Be defensive about what underlying fs provides us in the returned xattr
list buffer.  If it's not properly null terminated, bail out with a warning
insead of BUG.

Signed-off-by: Miklos Szeredi 
Signed-off-by: Greg Kroah-Hartman

ovl: remove posix_acl_default from workdir

2016-09-15T06:20:28+00:00

commit c11b9fdd6a612f376a5e886505f1c54c16d8c380 upstream.

Clear out posix acl xattrs on workdir and also reset the mode after
creation so that an inherited sgid bit is cleared.

Signed-off-by: Miklos Szeredi 
Signed-off-by: Greg Kroah-Hartman

ovl: don't copy up opaqueness

2016-09-15T06:20:28+00:00

commit 0956254a2d5b9e2141385514553aeef694dfe3b5 upstream.

When a copy up of a directory occurs which has the opaque xattr set, the
xattr remains in the upper directory. The immediate behavior with overlayfs
is that the upper directory is not treated as opaque, however after a
remount the opaque flag is used and upper directory is treated as opaque.
This causes files created in the lower layer to be hidden when using
multiple lower directories.

Fix by not copying up the opaque flag.

To reproduce:

 ----8<---------8<---------8<---------8<---------8<---------8<----
mkdir -p l/d/s u v w mnt
mount -t overlay overlay -olowerdir=l,upperdir=u,workdir=w mnt
rm -rf mnt/d/
mkdir -p mnt/d/n
umount mnt
mount -t overlay overlay -olowerdir=u:l,upperdir=v,workdir=w mnt
touch mnt/d/foo
umount mnt
mount -t overlay overlay -olowerdir=u:l,upperdir=v,workdir=w mnt
ls mnt/d
 ----8<---------8<---------8<---------8<---------8<---------8<----

output should be:  "foo  n"

Reported-by: Derek McGowan 
Link: https://bugzilla.kernel.org/show_bug.cgi?id=151291
Signed-off-by: Miklos Szeredi 
Signed-off-by: Greg Kroah-Hartman

ovl: proper cleanup of workdir

2016-09-15T06:20:28+00:00

commit eea2fb4851e9dcbab6b991aaf47e2e024f1f55a0 upstream.

When mounting overlayfs it needs a clean "work" directory under the
supplied workdir.

Previously the mount code removed this directory if it already existed and
created a new one.  If the removal failed (e.g. directory was not empty)
then it fell back to a read-only mount not using the workdir.

While this has never been reported, it is possible to get a non-empty
"work" dir from a previous mount of overlayfs in case of crash in the
middle of an operation using the work directory.

In this case the left over state should be discarded and the overlay
filesystem will be consistent, guaranteed by the atomicity of operations on
moving to/from the workdir to the upper layer.

This patch implements cleaning out any files left in workdir.  It is
implemented using real recursion for simplicity, but the depth is limited
to 2, because the worst case is that of a directory containing whiteouts
under "work".

Signed-off-by: Miklos Szeredi 
Signed-off-by: Greg Kroah-Hartman