1. 14 Nov, 2014 28 commits
  2. 13 Nov, 2014 12 commits
    • Jan Kara's avatar
      mm: Remove false WARN_ON from pagecache_isize_extended() · ae2490a0
      Jan Kara authored
      commit f55fefd1 upstream.
      
      The WARN_ON checking whether i_mutex is held in
      pagecache_isize_extended() was wrong because some filesystems (e.g.
      XFS) use different locks for serialization of truncates / writes. So
      just remove the check.
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Reviewed-by: default avatarDave Chinner <dchinner@redhat.com>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      ae2490a0
    • Eric W. Biederman's avatar
      mnt: Prevent pivot_root from creating a loop in the mount tree · 31b7cb6b
      Eric W. Biederman authored
      commit 0d082601 upstream.
      
      Andy Lutomirski recently demonstrated that when chroot is used to set
      the root path below the path for the new ``root'' passed to pivot_root
      the pivot_root system call succeeds and leaks mounts.
      
      In examining the code I see that starting with a new root that is
      below the current root in the mount tree will result in a loop in the
      mount tree after the mounts are detached and then reattached to one
      another.  Resulting in all kinds of ugliness including a leak of that
      mounts involved in the leak of the mount loop.
      
      Prevent this problem by ensuring that the new mount is reachable from
      the current root of the mount tree.
      
      [Added stable cc.  Fixes CVE-2014-7970.  --Andy]
      Reported-by: default avatarAndy Lutomirski <luto@amacapital.net>
      Reviewed-by: default avatarAndy Lutomirski <luto@amacapital.net>
      Link: http://lkml.kernel.org/r/87bnpmihks.fsf@x220.int.ebiederm.orgSigned-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarAndy Lutomirski <luto@amacapital.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      31b7cb6b
    • Andy Lutomirski's avatar
      x86_64, entry: Fix out of bounds read on sysenter · 83e8cfda
      Andy Lutomirski authored
      commit 653bc77a upstream.
      
      Rusty noticed a Really Bad Bug (tm) in my NT fix.  The entry code
      reads out of bounds, causing the NT fix to be unreliable.  But, and
      this is much, much worse, if your stack is somehow just below the
      top of the direct map (or a hole), you read out of bounds and crash.
      
      Excerpt from the crash:
      
      [    1.129513] RSP: 0018:ffff88001da4bf88  EFLAGS: 00010296
      
        2b:*    f7 84 24 90 00 00 00     testl  $0x4000,0x90(%rsp)
      
      That read is deterministically above the top of the stack.  I
      thought I even single-stepped through this code when I wrote it to
      check the offset, but I clearly screwed it up.
      
      Fixes: 8c7aa698 ("x86_64, entry: Filter RFLAGS.NT on entry from userspace")
      Reported-by: default avatarRusty Russell <rusty@ozlabs.org>
      Signed-off-by: default avatarAndy Lutomirski <luto@amacapital.net>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      83e8cfda
    • Andy Lutomirski's avatar
      x86_64, entry: Filter RFLAGS.NT on entry from userspace · 04de774b
      Andy Lutomirski authored
      commit 8c7aa698 upstream.
      
      The NT flag doesn't do anything in long mode other than causing IRET
      to #GP.  Oddly, CPL3 code can still set NT using popf.
      
      Entry via hardware or software interrupt clears NT automatically, so
      the only relevant entries are fast syscalls.
      
      If user code causes kernel code to run with NT set, then there's at
      least some (small) chance that it could cause trouble.  For example,
      user code could cause a call to EFI code with NT set, and who knows
      what would happen?  Apparently some games on Wine sometimes do
      this (!), and, if an IRET return happens, they will segfault.  That
      segfault cannot be handled, because signal delivery fails, too.
      
      This patch programs the CPU to clear NT on entry via SYSCALL (both
      32-bit and 64-bit, by my reading of the AMD APM), and it clears NT
      in software on entry via SYSENTER.
      
      To save a few cycles, this borrows a trick from Jan Beulich in Xen:
      it checks whether NT is set before trying to clear it.  As a result,
      it seems to have very little effect on SYSENTER performance on my
      machine.
      
      There's another minor bug fix in here: it looks like the CFI
      annotations were wrong if CONFIG_AUDITSYSCALL=n.
      
      Testers beware: on Xen, SYSENTER with NT set turns into a GPF.
      
      I haven't touched anything on 32-bit kernels.
      
      The syscall mask change comes from a variant of this patch by Anish
      Bhatt.
      
      Note to stable maintainers: there is no known security issue here.
      A misguided program can set NT and cause the kernel to try and fail
      to deliver SIGSEGV, crashing the program.  This patch fixes Far Cry
      on Wine: https://bugs.winehq.org/show_bug.cgi?id=33275Reported-by: default avatarAnish Bhatt <anish@chelsio.com>
      Signed-off-by: default avatarAndy Lutomirski <luto@amacapital.net>
      Link: http://lkml.kernel.org/r/395749a5d39a29bd3e4b35899cf3a3c1340e5595.1412189265.git.luto@amacapital.netSigned-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      04de774b
    • Rabin Vincent's avatar
      tracing/syscalls: Ignore numbers outside NR_syscalls' range · 9f156016
      Rabin Vincent authored
      commit 086ba77a upstream.
      
      ARM has some private syscalls (for example, set_tls(2)) which lie
      outside the range of NR_syscalls.  If any of these are called while
      syscall tracing is being performed, out-of-bounds array access will
      occur in the ftrace and perf sys_{enter,exit} handlers.
      
       # trace-cmd record -e raw_syscalls:* true && trace-cmd report
       ...
       true-653   [000]   384.675777: sys_enter:            NR 192 (0, 1000, 3, 4000022, ffffffff, 0)
       true-653   [000]   384.675812: sys_exit:             NR 192 = 1995915264
       true-653   [000]   384.675971: sys_enter:            NR 983045 (76f74480, 76f74000, 76f74b28, 76f74480, 76f76f74, 1)
       true-653   [000]   384.675988: sys_exit:             NR 983045 = 0
       ...
      
       # trace-cmd record -e syscalls:* true
       [   17.289329] Unable to handle kernel paging request at virtual address aaaaaace
       [   17.289590] pgd = 9e71c000
       [   17.289696] [aaaaaace] *pgd=00000000
       [   17.289985] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
       [   17.290169] Modules linked in:
       [   17.290391] CPU: 0 PID: 704 Comm: true Not tainted 3.18.0-rc2+ #21
       [   17.290585] task: 9f4dab00 ti: 9e710000 task.ti: 9e710000
       [   17.290747] PC is at ftrace_syscall_enter+0x48/0x1f8
       [   17.290866] LR is at syscall_trace_enter+0x124/0x184
      
      Fix this by ignoring out-of-NR_syscalls-bounds syscall numbers.
      
      Commit cd0980fc "tracing: Check invalid syscall nr while tracing syscalls"
      added the check for less than zero, but it should have also checked
      for greater than NR_syscalls.
      
      Link: http://lkml.kernel.org/p/1414620418-29472-1-git-send-email-rabin@rab.in
      
      Fixes: cd0980fc "tracing: Check invalid syscall nr while tracing syscalls"
      Signed-off-by: default avatarRabin Vincent <rabin@rab.in>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      9f156016
    • Eric Rannaud's avatar
      fs: allow open(dir, O_TMPFILE|..., 0) with mode 0 · cd8d57dc
      Eric Rannaud authored
      commit 69a91c23 upstream.
      
      The man page for open(2) indicates that when O_CREAT is specified, the
      'mode' argument applies only to future accesses to the file:
      
      	Note that this mode applies only to future accesses of the newly
      	created file; the open() call that creates a read-only file
      	may well return a read/write file descriptor.
      
      The man page for open(2) implies that 'mode' is treated identically by
      O_CREAT and O_TMPFILE.
      
      O_TMPFILE, however, behaves differently:
      
      	int fd = open("/tmp", O_TMPFILE | O_RDWR, 0);
      	assert(fd == -1);
      	assert(errno == EACCES);
      
      	int fd = open("/tmp", O_TMPFILE | O_RDWR, 0600);
      	assert(fd > 0);
      
      For O_CREAT, do_last() sets acc_mode to MAY_OPEN only:
      
      	if (*opened & FILE_CREATED) {
      		/* Don't check for write permission, don't truncate */
      		open_flag &= ~O_TRUNC;
      		will_truncate = false;
      		acc_mode = MAY_OPEN;
      		path_to_nameidata(path, nd);
      		goto finish_open_created;
      	}
      
      But for O_TMPFILE, do_tmpfile() passes the full op->acc_mode to
      may_open().
      
      This patch lines up the behavior of O_TMPFILE with O_CREAT. After the
      inode is created, may_open() is called with acc_mode = MAY_OPEN, in
      do_tmpfile().
      
      A different, but related glibc bug revealed the discrepancy:
      https://sourceware.org/bugzilla/show_bug.cgi?id=17523
      
      The glibc lazily loads the 'mode' argument of open() and openat() using
      va_arg() only if O_CREAT is present in 'flags' (to support both the 2
      argument and the 3 argument forms of open; same idea for openat()).
      However, the glibc ignores the 'mode' argument if O_TMPFILE is in
      'flags'.
      
      On x86_64, for open(), it magically works anyway, as 'mode' is in
      RDX when entering open(), and is still in RDX on SYSCALL, which is where
      the kernel looks for the 3rd argument of a syscall.
      
      But openat() is not quite so lucky: 'mode' is in RCX when entering the
      glibc wrapper for openat(), while the kernel looks for the 4th argument
      of a syscall in R10. Indeed, the syscall calling convention differs from
      the regular calling convention in this respect on x86_64. So the kernel
      sees mode = 0 when trying to use glibc openat() with O_TMPFILE, and
      fails with EACCES.
      Signed-off-by: default avatarEric Rannaud <e@nanocritical.com>
      Acked-by: default avatarAndy Lutomirski <luto@amacapital.net>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      cd8d57dc
    • Cyril Brulebois's avatar
      wireless: rt2x00: add new rt2800usb device · 8f32bd28
      Cyril Brulebois authored
      commit 664d6a79 upstream.
      
      0x1b75 0xa200 AirLive WN-200USB wireless 11b/g/n dongle
      
      References: https://bugs.debian.org/766802Reported-by: default avatarMartin Mokrejs <mmokrejs@fold.natur.cuni.cz>
      Signed-off-by: default avatarCyril Brulebois <kibi@debian.org>
      Acked-by: default avatarStanislaw Gruszka <sgruszka@redhat.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      8f32bd28
    • Greg Kroah-Hartman's avatar
      PCI: Rename sysfs 'enabled' file back to 'enable' · aac55dd6
      Greg Kroah-Hartman authored
      commit d8e7d53a upstream.
      
      Back in commit 5136b2da ("PCI: convert bus code to use dev_groups"),
      I misstyped the 'enable' sysfs filename as 'enabled', which broke the
      userspace API.  This patch fixes that issue by renaming the file back.
      
      Fixes: 5136b2da ("PCI: convert bus code to use dev_groups")
      Reported-by: default avatarJeff Epler <jepler@unpythonic.net>
      Tested-by: Jeff Epler <jepler@unpythonic.net>	# on v3.14-rt
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      aac55dd6
    • Jan Kara's avatar
      ext4: bail out from make_indexed_dir() on first error · 3bcbcf2f
      Jan Kara authored
      commit 6050d47a upstream.
      
      When ext4_handle_dirty_dx_node() or ext4_handle_dirty_dirent_node()
      fail, there's really something wrong with the fs and there's no point in
      continuing further. Just return error from make_indexed_dir() in that
      case. Also initialize frames array so that if we return early due to
      error, dx_release() doesn't try to dereference uninitialized memory
      (which could happen also due to error in do_split()).
      
      Coverity-id: 741300
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      3bcbcf2f
    • Theodore Ts'o's avatar
      ext4: convert do_split() to use the ERR_PTR convention · 401bd723
      Theodore Ts'o authored
      commit f8b3b59d upstream.
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      [ luis: backported to 3.16: useful for:
        6050d47a "ext4: bail out from make_indexed_dir() on first error" ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      401bd723
    • Dmitry Monakhov's avatar
      ext4: prevent bugon on race between write/fcntl · 01eca100
      Dmitry Monakhov authored
      commit a41537e6 upstream.
      
      O_DIRECT flags can be toggeled via fcntl(F_SETFL). But this value checked
      twice inside ext4_file_write_iter() and __generic_file_write() which
      result in BUG_ON inside ext4_direct_IO.
      
      Let's initialize iocb->private unconditionally.
      
      TESTCASE: xfstest:generic/036  https://patchwork.ozlabs.org/patch/402445/
      
      #TYPICAL STACK TRACE:
      kernel BUG at fs/ext4/inode.c:2960!
      invalid opcode: 0000 [#1] SMP
      Modules linked in: brd iTCO_wdt lpc_ich mfd_core igb ptp dm_mirror dm_region_hash dm_log dm_mod
      CPU: 6 PID: 5505 Comm: aio-dio-fcntl-r Not tainted 3.17.0-rc2-00176-gff5c017 #161
      Hardware name: Intel Corporation W2600CR/W2600CR, BIOS SE5C600.86B.99.99.x028.061320111235 06/13/2011
      task: ffff88080e95a7c0 ti: ffff88080f908000 task.ti: ffff88080f908000
      RIP: 0010:[<ffffffff811fabf2>]  [<ffffffff811fabf2>] ext4_direct_IO+0x162/0x3d0
      RSP: 0018:ffff88080f90bb58  EFLAGS: 00010246
      RAX: 0000000000000400 RBX: ffff88080fdb2a28 RCX: 00000000a802c818
      RDX: 0000040000080000 RSI: ffff88080d8aeb80 RDI: 0000000000000001
      RBP: ffff88080f90bbc8 R08: 0000000000000000 R09: 0000000000001581
      R10: 0000000000000000 R11: 0000000000000000 R12: ffff88080d8aeb80
      R13: ffff88080f90bbf8 R14: ffff88080fdb28c8 R15: ffff88080fdb2a28
      FS:  00007f23b2055700(0000) GS:ffff880818400000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007f23b2045000 CR3: 000000080cedf000 CR4: 00000000000407e0
      Stack:
       ffff88080f90bb98 0000000000000000 7ffffffffffffffe ffff88080fdb2c30
       0000000000000200 0000000000000200 0000000000000001 0000000000000200
       ffff88080f90bbc8 ffff88080fdb2c30 ffff88080f90be08 0000000000000200
      Call Trace:
       [<ffffffff8112ca9d>] generic_file_direct_write+0xed/0x180
       [<ffffffff8112f2b2>] __generic_file_write_iter+0x222/0x370
       [<ffffffff811f495b>] ext4_file_write_iter+0x34b/0x400
       [<ffffffff811bd709>] ? aio_run_iocb+0x239/0x410
       [<ffffffff811bd709>] ? aio_run_iocb+0x239/0x410
       [<ffffffff810990e5>] ? local_clock+0x25/0x30
       [<ffffffff810abd94>] ? __lock_acquire+0x274/0x700
       [<ffffffff811f4610>] ? ext4_unwritten_wait+0xb0/0xb0
       [<ffffffff811bd756>] aio_run_iocb+0x286/0x410
       [<ffffffff810990e5>] ? local_clock+0x25/0x30
       [<ffffffff810ac359>] ? lock_release_holdtime+0x29/0x190
       [<ffffffff811bc05b>] ? lookup_ioctx+0x4b/0xf0
       [<ffffffff811bde3b>] do_io_submit+0x55b/0x740
       [<ffffffff811bdcaa>] ? do_io_submit+0x3ca/0x740
       [<ffffffff811be030>] SyS_io_submit+0x10/0x20
       [<ffffffff815ce192>] system_call_fastpath+0x16/0x1b
      Code: 01 48 8b 80 f0 01 00 00 48 8b 18 49 8b 45 10 0f 85 f1 01 00 00 48 03 45 c8 48 3b 43 48 0f 8f e3 01 00 00 49 83 7c
      24 18 00 75 04 <0f> 0b eb fe f0 ff 83 ec 01 00 00 49 8b 44 24 18 8b 00 85 c0 89
      RIP  [<ffffffff811fabf2>] ext4_direct_IO+0x162/0x3d0
       RSP <ffff88080f90bb58>
      Reported-by: default avatarSasha Levin <sasha.levin@oracle.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarDmitry Monakhov <dmonakhov@openvz.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      01eca100
    • Darrick J. Wong's avatar
      ext4: enable journal checksum when metadata checksum feature enabled · 1bce1bd0
      Darrick J. Wong authored
      commit 98c1a759 upstream.
      
      If metadata checksumming is turned on for the FS, we need to tell the
      journal to use checksumming too.
      Signed-off-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      1bce1bd0