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

ovl: copy new uid/gid into overlayfs runtime inode

2016-03-22T15:11:10+00:00

[ Upstream commit b81de061fa59f17d2730aabb1b84419ef3913810 ]

Overlayfs must update uid/gid after chown, otherwise functions
like inode_owner_or_capable() will check user against stale uid.
Catched by xfstests generic/087, it chowns file and calls utimes.

Signed-off-by: Konstantin Khlebnikov 
Signed-off-by: Miklos Szeredi 
Cc: 
Signed-off-by: Sasha Levin

ovl: fix getcwd() failure after unsuccessful rmdir

2016-03-22T15:11:09+00:00

[ Upstream commit ce9113bbcbf45a57c082d6603b9a9f342be3ef74 ]

ovl_remove_upper() should do d_drop() only after it successfully
removes the dir, otherwise a subsequent getcwd() system call will
fail, breaking userspace programs.

This is to fix: https://bugzilla.kernel.org/show_bug.cgi?id=110491

Signed-off-by: Rui Wang 
Reviewed-by: Konstantin Khlebnikov 
Signed-off-by: Miklos Szeredi 
Cc: 
Signed-off-by: Sasha Levin

Fix cifs_uniqueid_to_ino_t() function for s390x

2016-03-11T14:45:23+00:00

[ Upstream commit 1ee9f4bd1a97026a7b2d7ae9f1f74b45680d0003 ]

This issue is caused by commit 02323db17e3a7 ("cifs: fix
cifs_uniqueid_to_ino_t not to ever return 0"), when BITS_PER_LONG
is 64 on s390x, the corresponding cifs_uniqueid_to_ino_t()
function will cast 64-bit fileid to 32-bit by using (ino_t)fileid,
because ino_t (typdefed __kernel_ino_t) is int type.

It's defined in arch/s390/include/uapi/asm/posix_types.h

    #ifndef __s390x__

    typedef unsigned long   __kernel_ino_t;
    ...
    #else /* __s390x__ */

    typedef unsigned int    __kernel_ino_t;

So the #ifdef condition is wrong for s390x, we can just still use
one cifs_uniqueid_to_ino_t() function with comparing sizeof(ino_t)
and sizeof(u64) to choose the correct execution accordingly.

Signed-off-by: Yadan Fan 
CC: stable 
Signed-off-by: Steve French 
Signed-off-by: Sasha Levin

CIFS: Fix SMB2+ interim response processing for read requests

2016-03-11T14:45:23+00:00

[ Upstream commit 6cc3b24235929b54acd5ecc987ef11a425bd209e ]

For interim responses we only need to parse a header and update
a number credits. Now it is done for all SMB2+ command except
SMB2_READ which is wrong. Fix this by adding such processing.

Signed-off-by: Pavel Shilovsky 
Tested-by: Shirish Pargaonkar 
CC: Stable 
Signed-off-by: Steve French 
Signed-off-by: Sasha Levin

cifs: fix out-of-bounds access in lease parsing

2016-03-11T14:45:23+00:00

[ Upstream commit deb7deff2f00bdbbcb3d560dad2a89ef37df837d ]

When opening a file, SMB2_open() attempts to parse the lease state from the
SMB2 CREATE Response.  However, the parsing code was not careful to ensure
that the create contexts are not empty or invalid, which can lead to out-
of-bounds memory access.  This can be seen easily by trying
to read a file from a OSX 10.11 SMB3 server.  Here is sample crash output:

BUG: unable to handle kernel paging request at ffff8800a1a77cc6
IP: [] SMB2_open+0x804/0x960
PGD 8f77067 PUD 0
Oops: 0000 [#1] SMP
Modules linked in:
CPU: 3 PID: 2876 Comm: cp Not tainted 4.5.0-rc3.x86_64.1+ #14
Hardware name: NETGEAR ReadyNAS 314          /ReadyNAS 314          , BIOS 4.6.5 10/11/2012
task: ffff880073cdc080 ti: ffff88005b31c000 task.ti: ffff88005b31c000
RIP: 0010:[]  [] SMB2_open+0x804/0x960
RSP: 0018:ffff88005b31fa08  EFLAGS: 00010282
RAX: 0000000000000015 RBX: 0000000000000000 RCX: 0000000000000006
RDX: 0000000000000000 RSI: 0000000000000246 RDI: ffff88007eb8c8b0
RBP: ffff88005b31fad8 R08: 666666203d206363 R09: 6131613030383866
R10: 3030383866666666 R11: 00000000000002b0 R12: ffff8800660fd800
R13: ffff8800a1a77cc2 R14: 00000000424d53fe R15: ffff88005f5a28c0
FS:  00007f7c8a2897c0(0000) GS:ffff88007eb80000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: ffff8800a1a77cc6 CR3: 000000005b281000 CR4: 00000000000006e0
Stack:
 ffff88005b31fa70 ffffffff88278789 00000000000001d3 ffff88005f5a2a80
 ffffffff00000003 ffff88005d029d00 ffff88006fde05a0 0000000000000000
 ffff88005b31fc78 ffff88006fde0780 ffff88005b31fb2f 0000000100000fe0
Call Trace:
 [] ? cifsConvertToUTF16+0x159/0x2d0
 [] smb2_open_file+0x98/0x210
 [] ? __kmalloc+0x1c/0xe0
 [] cifs_open+0x2a4/0x720
 [] do_dentry_open+0x1ff/0x310
 [] ? cifsFileInfo_get+0x30/0x30
 [] vfs_open+0x52/0x60
 [] path_openat+0x170/0xf70
 [] ? remove_wait_queue+0x48/0x50
 [] do_filp_open+0x79/0xd0
 [] ? __alloc_fd+0x3a/0x170
 [] do_sys_open+0x114/0x1e0
 [] SyS_open+0x19/0x20
 [] entry_SYSCALL_64_fastpath+0x12/0x6a
Code: 4d 8d 6c 07 04 31 c0 4c 89 ee e8 47 6f e5 ff 31 c9 41 89 ce 44 89 f1 48 c7 c7 28 b1 bd 88 31 c0 49 01 cd 4c 89 ee e8 2b 6f e5 ff <45> 0f b7 75 04 48 c7 c7 31 b1 bd 88 31 c0 4d 01 ee 4c 89 f6 e8
RIP  [] SMB2_open+0x804/0x960
 RSP 
CR2: ffff8800a1a77cc6
---[ end trace d9f69ba64feee469 ]---

Signed-off-by: Justin Maggard 
Signed-off-by: Steve French 
CC: Stable 
Signed-off-by: Sasha Levin

do_last(): don't let a bogus return value from ->open() et.al. to confuse us

2016-03-11T14:45:22+00:00

[ Upstream commit c80567c82ae4814a41287618e315a60ecf513be6 ]

... into returning a positive to path_openat(), which would interpret that
as "symlink had been encountered" and proceed to corrupt memory, etc.
It can only happen due to a bug in some ->open() instance or in some LSM
hook, etc., so we report any such event *and* make sure it doesn't trick
us into further unpleasantness.

Cc: stable@vger.kernel.org # v3.6+, at least
Signed-off-by: Al Viro 
Signed-off-by: Sasha Levin

hpfs: don't truncate the file when delete fails

2016-03-11T14:45:22+00:00

[ Upstream commit b6853f78e763d42c7a158d8de3549c9827c604ab ]

The delete opration can allocate additional space on the HPFS filesystem
due to btree split. The HPFS driver checks in advance if there is
available space, so that it won't corrupt the btree if we run out of space
during splitting.

If there is not enough available space, the HPFS driver attempted to
truncate the file, but this results in a deadlock since the commit
7dd29d8d865efdb00c0542a5d2c87af8c52ea6c7 ("HPFS: Introduce a global mutex
and lock it on every callback from VFS").

This patch removes the code that tries to truncate the file and -ENOSPC is
returned instead. If the user hits -ENOSPC on delete, he should try to
delete other files (that are stored in a leaf btree node), so that the
delete operation will make some space for deleting the file stored in
non-leaf btree node.

Reported-by: Al Viro 
Signed-off-by: Mikulas Patocka 
Cc: stable@vger.kernel.org	# 2.6.39+
Signed-off-by: Al Viro 
Signed-off-by: Sasha Levin

Fix directory hardlinks from deleted directories

2016-03-11T14:45:19+00:00

[ Upstream commit be629c62a603e5935f8177fd8a19e014100a259e ]

When a directory is deleted, we don't take too much care about killing off
all the dirents that belong to it — on the basis that on remount, the scan
will conclude that the directory is dead anyway.

This doesn't work though, when the deleted directory contained a child
directory which was moved *out*. In the early stages of the fs build
we can then end up with an apparent hard link, with the child directory
appearing both in its true location, and as a child of the original
directory which are this stage of the mount process we don't *yet* know
is defunct.

To resolve this, take out the early special-casing of the "directories
shall not have hard links" rule in jffs2_build_inode_pass1(), and let the
normal nlink processing happen for directories as well as other inodes.

Then later in the build process we can set ic->pino_nlink to the parent
inode#, as is required for directories during normal operaton, instead
of the nlink. And complain only *then* about hard links which are still
in evidence even after killing off all the unreachable paths.

Reported-by: Liu Song 
Signed-off-by: David Woodhouse 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

jffs2: Fix page lock / f->sem deadlock

2016-03-11T14:45:19+00:00

[ Upstream commit 49e91e7079febe59a20ca885a87dd1c54240d0f1 ]

With this fix, all code paths should now be obtaining the page lock before
f->sem.

Reported-by: Szabó Tamás 
Tested-by: Thomas Betker 
Signed-off-by: David Woodhouse 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

Revert "jffs2: Fix lock acquisition order bug in jffs2_write_begin"

2016-03-11T14:45:19+00:00

[ Upstream commit 157078f64b8a9cd7011b6b900b2f2498df850748 ]

This reverts commit 5ffd3412ae55
("jffs2: Fix lock acquisition order bug in jffs2_write_begin").

The commit modified jffs2_write_begin() to remove a deadlock with
jffs2_garbage_collect_live(), but this introduced new deadlocks found
by multiple users. page_lock() actually has to be called before
mutex_lock(&c->alloc_sem) or mutex_lock(&f->sem) because
jffs2_write_end() and jffs2_readpage() are called with the page locked,
and they acquire c->alloc_sem and f->sem, resp.

In other words, the lock order in jffs2_write_begin() was correct, and
it is the jffs2_garbage_collect_live() path that has to be changed.

Revert the commit to get rid of the new deadlocks, and to clear the way
for a better fix of the original deadlock.

Reported-by: Deng Chao 
Reported-by: Ming Liu 
Reported-by: wangzaiwei 
Signed-off-by: Thomas Betker 
Signed-off-by: David Woodhouse 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin