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

fs/dcache: move security_d_instantiate() behind attaching dentry to inode

2019-12-19T15:59:03+00:00

During backport 1e2e547a93a "do d_instantiate/unlock_new_inode
combinations safely", there was a error instantiating sequence of
attaching dentry to inode and calling security_d_instantiate().

Before commit ce23e640133 "->getxattr(): pass dentry and inode as
separate arguments" and b96809173e9 "security_d_instantiate(): move to
the point prior to attaching dentry to inode", security_d_instantiate()
should be called beind __d_instantiate(), otherwise it will trigger
below problem when CONFIG_SECURITY_SMACK on ext4 was enabled because
d_inode(dentry) used by ->getxattr() is NULL before __d_instantiate()
instantiate inode.

[   31.858026] BUG: unable to handle kernel paging request at ffffffffffffff70
...
[   31.882024] Call Trace:
[   31.882378]  [] ext4_xattr_get+0x8c/0x3e0
[   31.883195]  [] ext4_xattr_security_get+0x24/0x40
[   31.884086]  [] generic_getxattr+0x5b/0x90
[   31.884907]  [] smk_fetch+0xb4/0x150
[   31.885634]  [] smack_d_instantiate+0x1c2/0x550
[   31.886508]  [] security_d_instantiate+0x3a/0x80
[   31.887389]  [] d_instantiate_new+0x36/0x130
[   31.888223]  [] ext4_mkdir+0x4af/0x6a0
[   31.888928]  [] vfs_mkdir+0x100/0x280
[   31.889536]  [] SyS_mkdir+0xb6/0x170
[   31.890255]  [] ? trace_do_page_fault+0x95/0x2b0
[   31.891134]  [] entry_SYSCALL_64_fastpath+0x18/0x73

Cc:  # 3.16, 4.4
Signed-off-by: zhangyi (F) 
Signed-off-by: Ben Hutchings

ecryptfs_lookup_interpose(): lower_dentry->d_parent is not stable either

2019-12-19T15:58:59+00:00

commit 762c69685ff7ad5ad7fee0656671e20a0c9c864d upstream.

We need to get the underlying dentry of parent; sure, absent the races
it is the parent of underlying dentry, but there's nothing to prevent
losing a timeslice to preemtion in the middle of evaluation of
lower_dentry->d_parent->d_inode, having another process move lower_dentry
around and have its (ex)parent not pinned anymore and freed on memory
pressure.  Then we regain CPU and try to fetch ->d_inode from memory
that is freed by that point.

dentry->d_parent *is* stable here - it's an argument of ->lookup() and
we are guaranteed that it won't be moved anywhere until we feed it
to d_add/d_splice_alias.  So we safely go that way to get to its
underlying dentry.

Signed-off-by: Al Viro 
[bwh: Backported to 3.16:
 - Open-code d_inode()
 - Adjust context]
Signed-off-by: Ben Hutchings

ecryptfs_lookup_interpose(): lower_dentry->d_inode is not stable

2019-12-19T15:58:59+00:00

commit e72b9dd6a5f17d0fb51f16f8685f3004361e83d0 upstream.

lower_dentry can't go from positive to negative (we have it pinned),
but it *can* go from negative to positive.  So fetching ->d_inode
into a local variable, doing a blocking allocation, checking that
now ->d_inode is non-NULL and feeding the value we'd fetched
earlier to a function that won't accept NULL is not a good idea.

Signed-off-by: Al Viro 
[bwh: Backported to 3.16:
 - Use ACCESS_ONCE() instead of READ_ONCE()
 - Adjust context]
Signed-off-by: Ben Hutchings

ceph: add missing check in d_revalidate snapdir handling

2019-12-19T15:58:50+00:00

commit 1f08529c84cfecaf1261ed9b7e17fab18541c58f upstream.

We should not play with dcache without parent locked...

Signed-off-by: Al Viro 
Signed-off-by: Jeff Layton 
Signed-off-by: Ilya Dryomov 
[bwh: Backported to 3.16:
 - Test ceph_mds_request::r_locked_dir
 - Adjust context]
Signed-off-by: Ben Hutchings

ceph: fix use-after-free in __ceph_remove_cap()

2019-12-19T15:58:49+00:00

commit ea60ed6fcf29eebc78f2ce91491e6309ee005a01 upstream.

KASAN reports a use-after-free when running xfstest generic/531, with the
following trace:

[  293.903362]  kasan_report+0xe/0x20
[  293.903365]  rb_erase+0x1f/0x790
[  293.903370]  __ceph_remove_cap+0x201/0x370
[  293.903375]  __ceph_remove_caps+0x4b/0x70
[  293.903380]  ceph_evict_inode+0x4e/0x360
[  293.903386]  evict+0x169/0x290
[  293.903390]  __dentry_kill+0x16f/0x250
[  293.903394]  dput+0x1c6/0x440
[  293.903398]  __fput+0x184/0x330
[  293.903404]  task_work_run+0xb9/0xe0
[  293.903410]  exit_to_usermode_loop+0xd3/0xe0
[  293.903413]  do_syscall_64+0x1a0/0x1c0
[  293.903417]  entry_SYSCALL_64_after_hwframe+0x44/0xa9

This happens because __ceph_remove_cap() may queue a cap release
(__ceph_queue_cap_release) which can be scheduled before that cap is
removed from the inode list with

	rb_erase(&cap->ci_node, &ci->i_caps);

And, when this finally happens, the use-after-free will occur.

This can be fixed by removing the cap from the inode list before being
removed from the session list, and thus eliminating the risk of an UAF.

Signed-off-by: Luis Henriques 
Reviewed-by: Jeff Layton 
Signed-off-by: Ilya Dryomov 
Signed-off-by: Ben Hutchings

fuse: truncate pending writes on O_TRUNC

2019-12-19T15:58:42+00:00

commit e4648309b85a78f8c787457832269a8712a8673e upstream.

Make sure cached writes are not reordered around open(..., O_TRUNC), with
the obvious wrong results.

Fixes: 4d99ff8f12eb ("fuse: Turn writeback cache on")
Signed-off-by: Miklos Szeredi 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

fuse: flush dirty data/metadata before non-truncate setattr

2019-12-19T15:58:42+00:00

commit b24e7598db62386a95a3c8b9c75630c5d56fe077 upstream.

If writeback cache is enabled, then writes might get reordered with
chmod/chown/utimes.  The problem with this is that performing the write in
the fuse daemon might itself change some of these attributes.  In such case
the following sequence of operations will result in file ending up with the
wrong mode, for example:

  int fd = open ("suid", O_WRONLY|O_CREAT|O_EXCL);
  write (fd, "1", 1);
  fchown (fd, 0, 0);
  fchmod (fd, 04755);
  close (fd);

This patch fixes this by flushing pending writes before performing
chown/chmod/utimes.

Reported-by: Giuseppe Scrivano 
Tested-by: Giuseppe Scrivano 
Fixes: 4d99ff8f12eb ("fuse: Turn writeback cache on")
Signed-off-by: Miklos Szeredi 
Signed-off-by: Ben Hutchings

CIFS: avoid using MID 0xFFFF

2019-12-19T15:58:40+00:00

commit 03d9a9fe3f3aec508e485dd3dcfa1e99933b4bdb upstream.

According to MS-CIFS specification MID 0xFFFF should not be used by the
CIFS client, but we actually do. Besides, this has proven to cause races
leading to oops between SendReceive2/cifs_demultiplex_thread. On SMB1,
MID is a 2 byte value easy to reach in CurrentMid which may conflict with
an oplock break notification request coming from server

Signed-off-by: Roberto Bergantinos Corpas 
Reviewed-by: Ronnie Sahlberg 
Reviewed-by: Aurelien Aptel 
Signed-off-by: Steve French 
Signed-off-by: Ben Hutchings

Btrfs: check for the full sync flag while holding the inode lock during fsync

2019-12-19T15:58:36+00:00

commit ba0b084ac309283db6e329785c1dc4f45fdbd379 upstream.

We were checking for the full fsync flag in the inode before locking the
inode, which is racy, since at that that time it might not be set but
after we acquire the inode lock some other task set it. One case where
this can happen is on a system low on memory and some concurrent task
failed to allocate an extent map and therefore set the full sync flag on
the inode, to force the next fsync to work in full mode.

A consequence of missing the full fsync flag set is hitting the problems
fixed by commit 0c713cbab620 ("Btrfs: fix race between ranged fsync and
writeback of adjacent ranges"), BUG_ON() when dropping extents from a log
tree, hitting assertion failures at tree-log.c:copy_items() or all sorts
of weird inconsistencies after replaying a log due to file extents items
representing ranges that overlap.

So just move the check such that it's done after locking the inode and
before starting writeback again.

Fixes: 0c713cbab620 ("Btrfs: fix race between ranged fsync and writeback of adjacent ranges")
Signed-off-by: Filipe Manana 
Signed-off-by: David Sterba 
[bwh: Backported to 3.16:
 - Keep the "len" variable since we pass it to btrfs_wait_ordered_range()
   in two different places here
 - Adjust context]
Signed-off-by: Ben Hutchings

ceph: just skip unrecognized info in ceph_reply_info_extra

2019-12-19T15:58:30+00:00

commit 1d3f87233e26362fc3d4e59f0f31a71b570f90b9 upstream.

In the future, we're going to want to extend the ceph_reply_info_extra
for create replies. Currently though, the kernel code doesn't accept an
extra blob that is larger than the expected data.

Change the code to skip over any unrecognized fields at the end of the
extra blob, rather than returning -EIO.

Signed-off-by: Jeff Layton 
Signed-off-by: Ilya Dryomov 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings