user/sven/linux.git, branch v3.14.10

Linux 3.14.10

2014-07-01T03:12:08Z

efi-pstore: Fix an overflow on 32-bit builds

2014-07-01T03:12:02Z

commit 783ee43118dc773bc8b0342c5b230e017d5a04d0 upstream. In generic_id the long int timestamp is multiplied by 100000 and needs an explicit cast to u64. Without that the id in the resulting pstore filename is wrong and userspace may have problems parsing it, but more importantly files in pstore can never be deleted and may fill the EFI flash (brick device?). This happens because when generic pstore code wants to delete a file, it passes the id to the EFI backend which reinterpretes it and a wrong variable name is attempted to be deleted. There's no error message but after remounting pstore, deleted files would reappear. Signed-off-by: Andrew Zaborowski Acked-by: David Rientjes Signed-off-by: Matt Fleming Signed-off-by: Greg Kroah-Hartman

builddeb: use $OBJCOPY variable instead of objcopy

2014-07-01T03:12:02Z

commit 6b4a144a92ab81a1f45fb9b12aebaaaee0d08120 upstream. In cross-build environment, we expect to use the cross-compiler objcopy instead of the host objcopy. It fixes following build failures: objcopy --only-keep-debug lib/modules/3.14/kernel/net/ipv6/xfrm6_mode_tunnel.ko /srv/build/linux/debian/dbgtmp/usr/lib/debug/lib/modules/3.14/kernel/net/ipv6/xfrm6_mode_tunnel.ko objcopy: Unable to recognise the format of the input file `lib/modules/3.14/kernel/net/ipv6/xfrm6_mode_tunnel.ko' Signed-off-by: Fathi Boudra Fixes: 810e843746b7 ('deb-pkg: split debug symbols in their own package') Reviewed-by: Ben Hutchings Signed-off-by: Michal Marek Signed-off-by: Greg Kroah-Hartman

epoll: fix use-after-free in eventpoll_release_file

2014-07-01T03:12:02Z

commit ebe06187bf2aec10d537ce4595e416035367d703 upstream. This fixes use-after-free of epi->fllink.next inside list loop macro. This loop actually releases elements in the body. The list is rcu-protected but here we cannot hold rcu_read_lock because we need to lock mutex inside. The obvious solution is to use list_for_each_entry_safe(). RCU-ness isn't essential because nobody can change this list under us, it's final fput for this file. The bug was introduced by ae10b2b4eb01 ("epoll: optimize EPOLL_CTL_DEL using rcu") Signed-off-by: Konstantin Khlebnikov Reported-by: Cyrill Gorcunov Cc: Sasha Levin Cc: Jason Baron Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

x86_32, entry: Do syscall exit work on badsys (CVE-2014-4508)

2014-07-01T03:12:02Z

commit 554086d85e71f30abe46fc014fea31929a7c6a8a upstream. The bad syscall nr paths are their own incomprehensible route through the entry control flow. Rearrange them to work just like syscalls that return -ENOSYS. This fixes an OOPS in the audit code when fast-path auditing is enabled and sysenter gets a bad syscall nr (CVE-2014-4508). This has probably been broken since Linux 2.6.27: af0575bba0 i386 syscall audit fast-path Cc: Roland McGrath Reported-by: Toralf Förster Signed-off-by: Andy Lutomirski Link: http://lkml.kernel.org/r/e09c499eade6fc321266dd6b54da7beb28d6991c.1403558229.git.luto@amacapital.net Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman

lz4: fix another possible overrun

2014-07-01T03:12:02Z

commit 4148c1f67abf823099b2d7db6851e4aea407f5ee upstream. There is one other possible overrun in the lz4 code as implemented by Linux at this point in time (which differs from the upstream lz4 codebase, but will get synced at in a future kernel release.) As pointed out by Don, we also need to check the overflow in the data itself. While we are at it, replace the odd error return value with just a "simple" -1 value as the return value is never used for anything other than a basic "did this work or not" check. Reported-by: "Don A. Bailey" Reported-by: Willy Tarreau Signed-off-by: Greg Kroah-Hartman

btrfs: allocate raid type kobjects dynamically

2014-07-01T03:12:02Z

commit c1895442be01c58449e3bf9272f22062a670e08f upstream. We are currently allocating space_info objects in an array when we allocate space_info. When a user does something like: # btrfs balance start -mconvert=raid1 -dconvert=raid1 /mnt # btrfs balance start -mconvert=single -dconvert=single /mnt -f # btrfs balance start -mconvert=raid1 -dconvert=raid1 / We can end up with memory corruption since the kobject hasn't been reinitialized properly and the name pointer was left set. The rationale behind allocating them statically was to avoid creating a separate kobject container that just contained the raid type. It used the index in the array to determine the index. Ultimately, though, this wastes more memory than it saves in all but the most complex scenarios and introduces kobject lifetime questions. This patch allocates the kobjects dynamically instead. Note that we also remove the kobject_get/put of the parent kobject since kobject_add and kobject_del do that internally. Signed-off-by: Jeff Mahoney Reported-by: David Sterba Signed-off-by: Chris Mason Signed-off-by: Greg Kroah-Hartman

btrfs: fix lockdep warning with reclaim lock inversion

2014-07-01T03:12:02Z

commit ed55b6ac077fe7f9c6490ff55172c4b563562d7c upstream. When encountering memory pressure, testers have run into the following lockdep warning. It was caused by __link_block_group calling kobject_add with the groups_sem held. kobject_add calls kvasprintf with GFP_KERNEL, which gets us into reclaim context. The kobject doesn't actually need to be added under the lock -- it just needs to ensure that it's only added for the first block group to be linked. ========================================================= [ INFO: possible irq lock inversion dependency detected ] 3.14.0-rc8-default #1 Not tainted --------------------------------------------------------- kswapd0/169 just changed the state of lock: (&delayed_node->mutex){+.+.-.}, at: [] __btrfs_release_delayed_node+0x3a/0x200 [btrfs] but this lock took another, RECLAIM_FS-unsafe lock in the past: (&found->groups_sem){+++++.} and interrupts could create inverse lock ordering between them. other info that might help us debug this: Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&found->groups_sem); local_irq_disable(); lock(&delayed_node->mutex); lock(&found->groups_sem); lock(&delayed_node->mutex); *** DEADLOCK *** 2 locks held by kswapd0/169: #0: (shrinker_rwsem){++++..}, at: [] shrink_slab+0x3a/0x160 #1: (&type->s_umount_key#27){++++..}, at: [] grab_super_passive+0x3f/0x90 Signed-off-by: Jeff Mahoney Signed-off-by: Chris Mason Signed-off-by: Greg Kroah-Hartman

btrfs: fix use of uninit "ret" in end_extent_writepage()

2014-07-01T03:12:02Z

commit 3e2426bd0eb980648449e7a2f5a23e3cd3c7725c upstream. If this condition in end_extent_writepage() is false: if (tree->ops && tree->ops->writepage_end_io_hook) we will then test an uninitialized "ret" at: ret = ret < 0 ? ret : -EIO; The test for ret is for the case where ->writepage_end_io_hook failed, and we'd choose that ret as the error; but if there is no ->writepage_end_io_hook, nothing sets ret. Initializing ret to 0 should be sufficient; if writepage_end_io_hook wasn't set, (!uptodate) means non-zero err was passed in, so we choose -EIO in that case. Signed-of-by: Eric Sandeen Signed-off-by: Chris Mason Signed-off-by: Greg Kroah-Hartman

Btrfs: fix scrub_print_warning to handle skinny metadata extents

2014-07-01T03:12:02Z

commit 6eda71d0c030af0fc2f68aaa676e6d445600855b upstream. The skinny extents are intepreted incorrectly in scrub_print_warning(), and end up hitting the BUG() in btrfs_extent_inline_ref_size. Reported-by: Konstantinos Skarlatos Signed-off-by: Liu Bo Signed-off-by: Chris Mason Signed-off-by: Greg Kroah-Hartman