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

efi: Make efivarfs entries immutable by default

2016-03-14T22:10:35+00:00

commit ed8b0de5a33d2a2557dce7f9429dca8cb5bc5879 upstream.

"rm -rf" is bricking some peoples' laptops because of variables being
used to store non-reinitializable firmware driver data that's required
to POST the hardware.

These are 100% bugs, and they need to be fixed, but in the mean time it
shouldn't be easy to *accidentally* brick machines.

We have to have delete working, and picking which variables do and don't
work for deletion is quite intractable, so instead make everything
immutable by default (except for a whitelist), and make tools that
aren't quite so broad-spectrum unset the immutable flag.

Signed-off-by: Peter Jones 
Tested-by: Lee, Chun-Yi 
Acked-by: Matthew Garrett 
Signed-off-by: Matt Fleming 
Signed-off-by: Jiri Slaby

efi: Use ucs2_as_utf8 in efivarfs instead of open coding a bad version

2016-03-14T22:10:33+00:00

commit e0d64e6a880e64545ad7d55786aa84ab76bac475 upstream.

Translate EFI's UCS-2 variable names to UTF-8 instead of just assuming
all variable names fit in ASCII.

Signed-off-by: Peter Jones 
Acked-by: Matthew Garrett 
Tested-by: Lee, Chun-Yi 
Signed-off-by: Matt Fleming 
Signed-off-by: Jiri Slaby

Fix directory hardlinks from deleted directories

2016-03-07T15:05:25+00:00

commit be629c62a603e5935f8177fd8a19e014100a259e upstream.

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 
Signed-off-by: Jiri Slaby

jffs2: Fix page lock / f->sem deadlock

2016-03-07T15:05:24+00:00

commit 49e91e7079febe59a20ca885a87dd1c54240d0f1 upstream.

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 
Signed-off-by: Jiri Slaby

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

2016-03-07T15:05:24+00:00

commit 157078f64b8a9cd7011b6b900b2f2498df850748 upstream.

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 
Signed-off-by: Jiri Slaby

CIFS: Fix SMB2+ interim response processing for read requests

2016-03-07T15:05:22+00:00

commit 6cc3b24235929b54acd5ecc987ef11a425bd209e upstream.

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 
Signed-off-by: Steve French 
Signed-off-by: Jiri Slaby

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

2016-03-07T15:05:22+00:00

commit deb7deff2f00bdbbcb3d560dad2a89ef37df837d upstream.

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 
Signed-off-by: Jiri Slaby

nfsd: fix problem with setting ACL on directories

2016-03-07T09:38:40+00:00

This is a regression of 3.12 stable commit
ba1816b40a87a3f3c4ca9cd54a593a10d87bd391 (nfsd: fix NFS regression).

If a non-inherited ACL is set on a directory, nfsd will try to set the Posix
default ACL to NULL.  This gets converted to "" by generic_setxattr().
As "" is not a valid posix acl attribute value, this results in an error.

So instead of setting the xattr to NULL, remove it.

Fixes: ba1816b40a ("nfsd: fix NFS regression")
Signed-off-by: NeilBrown 
Cc: Sergio Gelato 
Signed-off-by: Jiri Slaby

bio: return EINTR if copying to user space got interrupted

2016-03-04T08:48:15+00:00

commit 2d99b55d378c996b9692a0c93dd25f4ed5d58934 upstream.

Commit 35dc248383bbab0a7203fca4d722875bc81ef091 introduced a check for
current->mm to see if we have a user space context and only copies data
if we do. Now if an IO gets interrupted by a signal data isn't copied
into user space any more (as we don't have a user space context) but
user space isn't notified about it.

This patch modifies the behaviour to return -EINTR from bio_uncopy_user()
to notify userland that a signal has interrupted the syscall, otherwise
it could lead to a situation where the caller may get a buffer with
no data returned.

This can be reproduced by issuing SG_IO ioctl()s in one thread while
constantly sending signals to it.

[js] backport to 3.12

Fixes: 35dc248 [SCSI] sg: Fix user memory corruption when SG_IO is interrupted by a signal
Signed-off-by: Johannes Thumshirn 
Signed-off-by: Hannes Reinecke 
Signed-off-by: Jens Axboe 
Signed-off-by: Jiri Slaby

locks: fix unlock when fcntl_setlk races with a close

2016-03-03T12:19:34+00:00

commit 7f3697e24dc3820b10f445a4a7d914fc356012d1 upstream.

Dmitry reported that he was able to reproduce the WARN_ON_ONCE that
fires in locks_free_lock_context when the flc_posix list isn't empty.

The problem turns out to be that we're basically rebuilding the
file_lock from scratch in fcntl_setlk when we discover that the setlk
has raced with a close. If the l_whence field is SEEK_CUR or SEEK_END,
then we may end up with fl_start and fl_end values that differ from
when the lock was initially set, if the file position or length of the
file has changed in the interim.

Fix this by just reusing the same lock request structure, and simply
override fl_type value with F_UNLCK as appropriate. That ensures that
we really are unlocking the lock that was initially set.

While we're there, make sure that we do pop a WARN_ON_ONCE if the
removal ever fails. Also return -EBADF in this event, since that's
what we would have returned if the close had happened earlier.

Cc: Alexander Viro 
Fixes: c293621bbf67 (stale POSIX lock handling)
Reported-by: Dmitry Vyukov 
Signed-off-by: Jeff Layton 
Acked-by: "J. Bruce Fields" 
Signed-off-by: Jiri Slaby