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

d_walk() might skip too much

2015-07-04T02:48:09+00:00

When Al Viro's VFS deadlock fix "deal with deadlock in d_walk()" was
backported to 3.10.y 3.4.y and 3.2.y stable kernel brances, the deadlock fix
was copied to 3 different places. Later, a bug in that code was discovered.
Al Viro's fix involved fixing only one part of code in mainline kernel. That
fix is called "d_walk() might skip too much".

3.10.y 3.4.y and 3.2.y stable kernel brances need that later fix copied to 3
different places. Greg Kroah-Hartman included Al Viro's "d_walk() might skip
too much" fix only once in 3.10.80 kernel, leaving 2 more places without a
fix.

The patch below was not written by me. I only applied Al Viro's "d_walk()
might skip too much" fix 2 more times to 3.10.80 kernel, and cheched that
the fixes went to correct places. With this patch applied, all 3 places that
I am aware of 3.10.y stable branch are now fixed.

Signed-off-by: Jari Ruusu 
Cc: Willy Tarreau 
Signed-off-by: Greg Kroah-Hartman

Btrfs: make xattr replace operations atomic

2015-07-04T02:48:09+00:00

commit 5f5bc6b1e2d5a6f827bc860ef2dc5b6f365d1339 upstream.

Replacing a xattr consists of doing a lookup for its existing value, delete
the current value from the respective leaf, release the search path and then
finally insert the new value. This leaves a time window where readers (getxattr,
listxattrs) won't see any value for the xattr. Xattrs are used to store ACLs,
so this has security implications.

This change also fixes 2 other existing issues which were:

*) Deleting the old xattr value without verifying first if the new xattr will
   fit in the existing leaf item (in case multiple xattrs are packed in the
   same item due to name hash collision);

*) Returning -EEXIST when the flag XATTR_CREATE is given and the xattr doesn't
   exist but we have have an existing item that packs muliple xattrs with
   the same name hash as the input xattr. In this case we should return ENOSPC.

A test case for xfstests follows soon.

Thanks to Alexandre Oliva for reporting the non-atomicity of the xattr replace
implementation.

Reported-by: Alexandre Oliva 
Signed-off-by: Filipe Manana 
Signed-off-by: Chris Mason 
[shengyong: backport to 3.10
 - FIX: CVE-2014-9710
 - adjust context
 - ASSERT() was added v3.12, so we do check with if statement
 - set the first parameter of btrfs_item_nr() as NULL, because it is not
   used, and is removed in v3.13
]
Signed-off-by: Sheng Yong 
Signed-off-by: Greg Kroah-Hartman

fs: take i_mutex during prepare_binprm for set[ug]id executables

2015-07-04T02:48:09+00:00

commit 8b01fc86b9f425899f8a3a8fc1c47d73c2c20543 upstream.

This prevents a race between chown() and execve(), where chowning a
setuid-user binary to root would momentarily make the binary setuid
root.

This patch was mostly written by Linus Torvalds.

Signed-off-by: Jann Horn 
Signed-off-by: Linus Torvalds 
Signed-off-by: Charles Williams 
Signed-off-by: Jiri Slaby 
Signed-off-by: Sheng Yong 
Signed-off-by: Greg Kroah-Hartman

get rid of s_files and files_lock

2015-07-04T02:48:08+00:00

commit eee5cc2702929fd41cce28058dc6d6717f723f87 upstream.

The only thing we need it for is alt-sysrq-r (emergency remount r/o)
and these days we can do just as well without going through the
list of files.

Signed-off-by: Al Viro 
[wangkai: backport to 3.10: adjust context]
Signed-off-by: Wang Kai 
Signed-off-by: Greg Kroah-Hartman

fput: turn "list_head delayed_fput_list" into llist_head

2015-07-04T02:48:08+00:00

commit 4f5e65a1cc90bbb15b9f6cdc362922af1bcc155a upstream.

fput() and delayed_fput() can use llist and avoid the locking.

This is unlikely path, it is not that this change can improve
the performance, but this way the code looks simpler.

Signed-off-by: Oleg Nesterov 
Suggested-by: Andrew Morton 
Cc: Al Viro 
Cc: Andrey Vagin 
Cc: "Eric W. Biederman" 
Cc: David Howells 
Cc: Huang Ying 
Cc: Peter Zijlstra 
Signed-off-by: Andrew Morton 
Signed-off-by: Al Viro 
Signed-off-by: Wang Kai 
Signed-off-by: Greg Kroah-Hartman

pipe: iovec: Fix memory corruption when retrying atomic copy as non-atomic

2015-06-29T19:08:34+00:00

pipe_iov_copy_{from,to}_user() may be tried twice with the same iovec,
the first time atomically and the second time not.  The second attempt
needs to continue from the iovec position, pipe buffer offset and
remaining length where the first attempt failed, but currently the
pipe buffer offset and remaining length are reset.  This will corrupt
the piped data (possibly also leading to an information leak between
processes) and may also corrupt kernel memory.

This was fixed upstream by commits f0d1bec9d58d ("new helper:
copy_page_from_iter()") and 637b58c2887e ("switch pipe_read() to
copy_page_to_iter()"), but those aren't suitable for stable.  This fix
for older kernel versions was made by Seth Jennings for RHEL and I
have extracted it from their update.

CVE-2015-1805

References: https://bugzilla.redhat.com/show_bug.cgi?id=1202855
Signed-off-by: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman

btrfs: cleanup orphans while looking up default subvolume

2015-06-22T23:55:55+00:00

commit 727b9784b6085c99c2f836bf4fcc2848dc9cf904 upstream.

Orphans in the fs tree are cleaned up via open_ctree and subvolume
orphans are cleaned via btrfs_lookup_dentry -- except when a default
subvolume is in use.  The name for the default subvolume uses a manual
lookup that doesn't trigger orphan cleanup and needs to trigger it
manually as well. This doesn't apply to the remount case since the
subvolumes are cleaned up by walking the root radix tree.

Signed-off-by: Jeff Mahoney 
Reviewed-by: David Sterba 
Signed-off-by: Chris Mason 
Signed-off-by: Greg Kroah-Hartman

btrfs: incorrect handling for fiemap_fill_next_extent return

2015-06-22T23:55:55+00:00

commit 26e726afe01c1c82072cf23a5ed89ce25f39d9f2 upstream.

fiemap_fill_next_extent returns 0 on success, -errno on error, 1 if this was
the last extent that will fit in user array. If 1 is returned, the return
value may eventually returned to user space, which should not happen, according
to manpage of ioctl.

Signed-off-by: Chengyu Song 
Reviewed-by: David Sterba 
Reviewed-by: Liu Bo 
Signed-off-by: Chris Mason 
Signed-off-by: Greg Kroah-Hartman

fs/binfmt_elf.c:load_elf_binary(): return -EINVAL on zero-length mappings

2015-06-06T06:20:00+00:00

commit 2b1d3ae940acd11be44c6eced5873d47c2e00ffa upstream.

load_elf_binary() returns `retval', not `error'.

Fixes: a87938b2e246b81b4fb ("fs/binfmt_elf.c: fix bug in loading of PIE binaries")
Reported-by: James Hogan 
Cc: Michael Davidson 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

vfs: read file_handle only once in handle_to_path

2015-06-06T06:20:00+00:00

commit 161f873b89136eb1e69477c847d5a5033239d9ba upstream.

We used to read file_handle twice.  Once to get the amount of extra
bytes, and once to fetch the entire structure.

This may be problematic since we do size verifications only after the
first read, so if the number of extra bytes changes in userspace between
the first and second calls, we'll have an incoherent view of
file_handle.

Instead, read the constant size once, and copy that over to the final
structure without having to re-read it again.

Signed-off-by: Sasha Levin 
Cc: Al Viro 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman