1. 06 May, 2015 28 commits
  2. 29 Apr, 2015 12 commits
    • Greg Kroah-Hartman's avatar
      Linux 3.10.76 · 89bf6007
      Greg Kroah-Hartman authored
      89bf6007
    • Ben Hutchings's avatar
      dcache: Fix locking bugs in backported "deal with deadlock in d_walk()" · c190d250
      Ben Hutchings authored
      commit 20defcec upstream in 3.2-stable
      
      Steven Rostedt reported:
      > Porting -rt to the latest 3.2 stable tree I triggered this bug:
      >
      > =====================================
      > [ BUG: bad unlock balance detected! ]
      > -------------------------------------
      > rm/1638 is trying to release lock (rcu_read_lock) at:
      > [<c04fde6c>] rcu_read_unlock+0x0/0x23
      > but there are no more locks to release!
      >
      > other info that might help us debug this:
      > 2 locks held by rm/1638:
      >  #0:  (&sb->s_type->i_mutex_key#9/1){+.+.+.}, at: [<c04f93eb>] do_rmdir+0x5f/0xd2
      >  #1:  (&sb->s_type->i_mutex_key#9){+.+.+.}, at: [<c04f9329>] vfs_rmdir+0x49/0xac
      >
      > stack backtrace:
      > Pid: 1638, comm: rm Not tainted 3.2.66-test-rt96+ #2
      > Call Trace:
      >  [<c083f390>] ? printk+0x1d/0x1f
      >  [<c0463cdf>] print_unlock_inbalance_bug+0xc3/0xcd
      >  [<c04653a8>] lock_release_non_nested+0x98/0x1ec
      >  [<c046228d>] ? trace_hardirqs_off_caller+0x18/0x90
      >  [<c0456f1c>] ? local_clock+0x2d/0x50
      >  [<c04fde6c>] ? d_hash+0x2f/0x2f
      >  [<c04fde6c>] ? d_hash+0x2f/0x2f
      >  [<c046568e>] lock_release+0x192/0x1ad
      >  [<c04fde83>] rcu_read_unlock+0x17/0x23
      >  [<c04ff344>] shrink_dcache_parent+0x227/0x270
      >  [<c04f9348>] vfs_rmdir+0x68/0xac
      >  [<c04f9424>] do_rmdir+0x98/0xd2
      >  [<c04f03ad>] ? fput+0x1a3/0x1ab
      >  [<c084dd42>] ? sysenter_exit+0xf/0x1a
      >  [<c0465b58>] ? trace_hardirqs_on_caller+0x118/0x149
      >  [<c04fa3e0>] sys_unlinkat+0x2b/0x35
      >  [<c084dd13>] sysenter_do_call+0x12/0x12
      >
      >
      >
      >
      > There's a path to calling rcu_read_unlock() without calling
      > rcu_read_lock() in have_submounts().
      >
      > 	goto positive;
      >
      > positive:
      > 	if (!locked && read_seqretry(&rename_lock, seq))
      > 		goto rename_retry;
      >
      > rename_retry:
      > 	rcu_read_unlock();
      >
      > in the above path, rcu_read_lock() is never done before calling
      > rcu_read_unlock();
      
      I reviewed locking contexts in all three functions that I changed when
      backporting "deal with deadlock in d_walk()".  It's actually worse
      than this:
      
      - We don't hold this_parent->d_lock at the 'positive' label in
        have_submounts(), but it is unlocked after 'rename_retry'.
      - There is an rcu_read_unlock() after the 'out' label in
        select_parent(), but it's not held at the 'goto out'.
      
      Fix all three lock imbalances.
      Reported-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      Tested-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c190d250
    • Guenter Roeck's avatar
      arc: mm: Fix build failure · 9e505ae7
      Guenter Roeck authored
      commit e262eb93 upstream.
      
      Fix misspelled define.
      
      Fixes: 33692f27 ("vm: add VM_FAULT_SIGSEGV handling support")
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9e505ae7
    • Seth Jennings's avatar
      sb_edac: avoid INTERNAL ERROR message in EDAC with unspecified channel · ebe7e30a
      Seth Jennings authored
      commit 351fc4a9 upstream.
      
      Intel IA32 SDM Table 15-14 defines channel 0xf as 'not specified', but
      EDAC doesn't know about this and returns and INTERNAL ERROR when the
      channel is greater than NUM_CHANNELS:
      
      kernel: [ 1538.886456] CPU 0: Machine Check Exception: 0 Bank 1: 940000000000009f
      kernel: [ 1538.886669] TSC 2bc68b22e7e812 ADDR 46dae7000 MISC 0 PROCESSOR 0:306e4 TIME 1390414572 SOCKET 0 APIC 0
      kernel: [ 1538.971948] EDAC MC1: INTERNAL ERROR: channel value is out of range (15 >= 4)
      kernel: [ 1538.972203] EDAC MC1: 0 CE memory read error on unknown memory (slot:0 page:0x46dae7 offset:0x0 grain:0 syndrome:0x0 -  area:DRAM err_code:0000:009f socket:1 channel_mask:1 rank:0)
      
      This commit changes sb_edac to forward a channel of -1 to EDAC if the
      channel is not specified.  edac_mc_handle_error() sets the channel to -1
      internally after the error message anyway, so this commit should have no
      effect other than avoiding the INTERNAL ERROR message when the channel
      is not specified.
      Signed-off-by: default avatarSeth Jennings <sjenning@redhat.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      Cc: Vinson Lee <vlee@twopensource.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ebe7e30a
    • Linus Torvalds's avatar
      x86: mm: move mmap_sem unlock from mm_fault_error() to caller · 2d892c7a
      Linus Torvalds authored
      commit 7fb08eca upstream.
      
      This replaces four copies in various stages of mm_fault_error() handling
      with just a single one.  It will also allow for more natural placement
      of the unlocking after some further cleanup.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2d892c7a
    • Linus Torvalds's avatar
      vm: make stack guard page errors return VM_FAULT_SIGSEGV rather than SIGBUS · 1f74b26b
      Linus Torvalds authored
      commit 9c145c56 upstream.
      
      The stack guard page error case has long incorrectly caused a SIGBUS
      rather than a SIGSEGV, but nobody actually noticed until commit
      fee7e49d ("mm: propagate error from stack expansion even for guard
      page") because that error case was never actually triggered in any
      normal situations.
      
      Now that we actually report the error, people noticed the wrong signal
      that resulted.  So far, only the test suite of libsigsegv seems to have
      actually cared, but there are real applications that use libsigsegv, so
      let's not wait for any of those to break.
      Reported-and-tested-by: default avatarTakashi Iwai <tiwai@suse.de>
      Tested-by: default avatarJan Engelhardt <jengelh@inai.de>
      Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com> # "s390 still compiles and boots"
      Cc: linux-arch@vger.kernel.org
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1f74b26b
    • Linus Torvalds's avatar
      vm: add VM_FAULT_SIGSEGV handling support · 0c42d1fb
      Linus Torvalds authored
      commit 33692f27 upstream.
      
      The core VM already knows about VM_FAULT_SIGBUS, but cannot return a
      "you should SIGSEGV" error, because the SIGSEGV case was generally
      handled by the caller - usually the architecture fault handler.
      
      That results in lots of duplication - all the architecture fault
      handlers end up doing very similar "look up vma, check permissions, do
      retries etc" - but it generally works.  However, there are cases where
      the VM actually wants to SIGSEGV, and applications _expect_ SIGSEGV.
      
      In particular, when accessing the stack guard page, libsigsegv expects a
      SIGSEGV.  And it usually got one, because the stack growth is handled by
      that duplicated architecture fault handler.
      
      However, when the generic VM layer started propagating the error return
      from the stack expansion in commit fee7e49d ("mm: propagate error
      from stack expansion even for guard page"), that now exposed the
      existing VM_FAULT_SIGBUS result to user space.  And user space really
      expected SIGSEGV, not SIGBUS.
      
      To fix that case, we need to add a VM_FAULT_SIGSEGV, and teach all those
      duplicate architecture fault handlers about it.  They all already have
      the code to handle SIGSEGV, so it's about just tying that new return
      value to the existing code, but it's all a bit annoying.
      
      This is the mindless minimal patch to do this.  A more extensive patch
      would be to try to gather up the mostly shared fault handling logic into
      one generic helper routine, and long-term we really should do that
      cleanup.
      
      Just from this patch, you can generally see that most architectures just
      copied (directly or indirectly) the old x86 way of doing things, but in
      the meantime that original x86 model has been improved to hold the VM
      semaphore for shorter times etc and to handle VM_FAULT_RETRY and other
      "newer" things, so it would be a good idea to bring all those
      improvements to the generic case and teach other architectures about
      them too.
      Reported-and-tested-by: default avatarTakashi Iwai <tiwai@suse.de>
      Tested-by: default avatarJan Engelhardt <jengelh@inai.de>
      Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com> # "s390 still compiles and boots"
      Cc: linux-arch@vger.kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      [shengyong: Backport to 3.10
       - adjust context
       - ignore modification for arch nios2, because 3.10 does not support it
       - ignore modification for driver lustre, because 3.10 does not support it
       - ignore VM_FAULT_FALLBACK in VM_FAULT_ERROR, becase 3.10 does not support
         this flag
       - add SIGSEGV handling to powerpc/cell spu_fault.c, because 3.10 does not
         separate it to copro_fault.c
       - add SIGSEGV handling in mm/memory.c, because 3.10 does not separate it
         to gup.c
      ]
      Signed-off-by: default avatarSheng Yong <shengyong1@huawei.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0c42d1fb
    • Al Viro's avatar
      deal with deadlock in d_walk() · 5f03ac13
      Al Viro authored
      commit ca5358ef upstream.
      
      ... by not hitting rename_retry for reasons other than rename having
      happened.  In other words, do _not_ restart when finding that
      between unlocking the child and locking the parent the former got
      into __dentry_kill().  Skip the killed siblings instead...
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Cc: Ben Hutchings <ben@decadent.org.uk>
      [hujianyang: Backported to 3.10 refer to the work of Ben Hutchings in 3.2:
       - As we only have try_to_ascend() and not d_walk(), apply this
         change to all callers of try_to_ascend()
       - Adjust context to make __dentry_kill() apply to d_kill()]
      Signed-off-by: default avatarhujianyang <hujianyang@huawei.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5f03ac13
    • Al Viro's avatar
      move d_rcu from overlapping d_child to overlapping d_alias · 6637ecd3
      Al Viro authored
      commit 946e51f2 upstream.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Cc: Ben Hutchings <ben@decadent.org.uk>
      [hujianyang: Backported to 3.10 refer to the work of Ben Hutchings in 3.2:
       - Apply name changes in all the different places we use d_alias and d_child
       - Move the WARN_ON() in __d_free() to d_free() as we don't have dentry_free()]
      Signed-off-by: default avatarhujianyang <hujianyang@huawei.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6637ecd3
    • Peter Kümmel's avatar
      kconfig: Fix warning "‘jump’ may be used uninitialized" · f2b1b663
      Peter Kümmel authored
      commit 2d560306 upstream.
      
      Warning:
      In file included from scripts/kconfig/zconf.tab.c:2537:0:
      scripts/kconfig/menu.c: In function ‘get_symbol_str’:
      scripts/kconfig/menu.c:590:18: warning: ‘jump’ may be used uninitialized in this function [-Wmaybe-uninitialized]
           jump->offset = strlen(r->s);
      
      Simplifies the test logic because (head && local) means (jump != 0)
      and makes GCC happy when checking if the jump pointer was initialized.
      Signed-off-by: default avatarPeter Kümmel <syntheticpp@gmx.net>
      Signed-off-by: default avatarMichal Marek <mmarek@suse.cz>
      [ dileks: v2: Backported to fit v3.10 ]
      Cc: Sedat Dilek <sedat.dilek@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f2b1b663
    • Nadav Amit's avatar
      KVM: x86: SYSENTER emulation is broken · 3478a33e
      Nadav Amit authored
      commit f3747379 upstream.
      
      SYSENTER emulation is broken in several ways:
      1. It misses the case of 16-bit code segments completely (CVE-2015-0239).
      2. MSR_IA32_SYSENTER_CS is checked in 64-bit mode incorrectly (bits 0 and 1 can
         still be set without causing #GP).
      3. MSR_IA32_SYSENTER_EIP and MSR_IA32_SYSENTER_ESP are not masked in
         legacy-mode.
      4. There is some unneeded code.
      
      Fix it.
      Signed-off-by: default avatarNadav Amit <namit@cs.technion.ac.il>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      [zhangzhiqiang: backport to 3.10:
       - adjust context
       - in 3.10 context "ctxt->eflags &= ~(EFLG_VM | EFLG_IF | EFLG_RF)" is replaced by
         "ctxt->eflags &= ~(EFLG_VM | EFLG_IF)" in upstream, which was changed by another commit.
       - After the above adjustments, becomes same to the original patch:
             https://github.com/torvalds/linux/commit/f3747379accba8e95d70cec0eae0582c8c182050
      ]
      Signed-off-by: default avatarZhiqiang Zhang <zhangzhiqiang.zhang@huawei.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3478a33e
    • Florian Westphal's avatar
      netfilter: conntrack: disable generic tracking for known protocols · 752b388c
      Florian Westphal authored
      commit db29a950 upstream.
      
      Given following iptables ruleset:
      
      -P FORWARD DROP
      -A FORWARD -m sctp --dport 9 -j ACCEPT
      -A FORWARD -p tcp --dport 80 -j ACCEPT
      -A FORWARD -p tcp -m conntrack -m state ESTABLISHED,RELATED -j ACCEPT
      
      One would assume that this allows SCTP on port 9 and TCP on port 80.
      Unfortunately, if the SCTP conntrack module is not loaded, this allows
      *all* SCTP communication, to pass though, i.e. -p sctp -j ACCEPT,
      which we think is a security issue.
      
      This is because on the first SCTP packet on port 9, we create a dummy
      "generic l4" conntrack entry without any port information (since
      conntrack doesn't know how to extract this information).
      
      All subsequent packets that are unknown will then be in established
      state since they will fallback to proto_generic and will match the
      'generic' entry.
      
      Our originally proposed version [1] completely disabled generic protocol
      tracking, but Jozsef suggests to not track protocols for which a more
      suitable helper is available, hence we now mitigate the issue for in
      tree known ct protocol helpers only, so that at least NAT and direction
      information will still be preserved for others.
      
       [1] http://www.spinics.net/lists/netfilter-devel/msg33430.html
      
      Joint work with Daniel Borkmann.
      
      Fixes CVE-2014-8160.
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarDaniel Borkmann <dborkman@redhat.com>
      Acked-by: default avatarJozsef Kadlecsik <kadlec@blackhole.kfki.hu>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: default avatarZhiqiang Zhang <zhangzhiqiang.zhang@huawei.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      752b388c