1. 23 Feb, 2017 40 commits
    • Chris Brandt's avatar
      sh_eth: remove unchecked interrupts for RZ/A1 · e07d83a4
      Chris Brandt authored
      commit 33d446db upstream.
      
      When streaming a lot of data and the RZ/A1 can't keep up, some status bits
      will get set that are not being checked or cleared which cause the
      following messages and the Ethernet driver to stop working. This
      patch fixes that issue.
      
      irq 21: nobody cared (try booting with the "irqpoll" option)
      handlers:
      [<c036b71c>] sh_eth_interrupt
      Disabling IRQ #21
      
      Fixes: db893473 ("sh_eth: Add support for r7s72100")
      Signed-off-by: default avatarChris Brandt <chris.brandt@renesas.com>
      Acked-by: default avatarSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      e07d83a4
    • Florian Fainelli's avatar
      net: bcmgenet: Utilize correct struct device for all DMA operations · a0579d7e
      Florian Fainelli authored
      commit 8c4799ac upstream.
      
      __bcmgenet_tx_reclaim() and bcmgenet_free_rx_buffers() are not using the
      same struct device during unmap that was used for the map operation,
      which makes DMA-API debugging warn about it. Fix this by always using
      &priv->pdev->dev throughout the driver, using an identical device
      reference for all map/unmap calls.
      
      Fixes: 1c1008c7 ("net: bcmgenet: add main driver file")
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [bwh: Backported to 3.16:
       - Adjust context
       - Also fix call from bcmgenet_desc_rx(), fixed upstream in commit
         d6707bec "net: bcmgenet: rewrite bcmgenet_rx_refill()"]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      a0579d7e
    • Eli Cooper's avatar
      ipv6: Set skb->protocol properly for local output · 770e9171
      Eli Cooper authored
      commit b4e479a9 upstream.
      
      When xfrm is applied to TSO/GSO packets, it follows this path:
      
          xfrm_output() -> xfrm_output_gso() -> skb_gso_segment()
      
      where skb_gso_segment() relies on skb->protocol to function properly.
      
      This patch sets skb->protocol to ETH_P_IPV6 before dst_output() is called,
      fixing a bug where GSO packets sent through an ipip6 tunnel are dropped
      when xfrm is involved.
      Signed-off-by: default avatarEli Cooper <elicooper@gmx.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      770e9171
    • Eli Cooper's avatar
      ipv4: Set skb->protocol properly for local output · bb8815da
      Eli Cooper authored
      commit f4180439 upstream.
      
      When xfrm is applied to TSO/GSO packets, it follows this path:
      
          xfrm_output() -> xfrm_output_gso() -> skb_gso_segment()
      
      where skb_gso_segment() relies on skb->protocol to function properly.
      
      This patch sets skb->protocol to ETH_P_IP before dst_output() is called,
      fixing a bug where GSO packets sent through a sit tunnel are dropped
      when xfrm is involved.
      Signed-off-by: default avatarEli Cooper <elicooper@gmx.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      bb8815da
    • Philip Pettersson's avatar
      packet: fix race condition in packet_set_ring · 943e7299
      Philip Pettersson authored
      commit 84ac7260 upstream.
      
      When packet_set_ring creates a ring buffer it will initialize a
      struct timer_list if the packet version is TPACKET_V3. This value
      can then be raced by a different thread calling setsockopt to
      set the version to TPACKET_V1 before packet_set_ring has finished.
      
      This leads to a use-after-free on a function pointer in the
      struct timer_list when the socket is closed as the previously
      initialized timer will not be deleted.
      
      The bug is fixed by taking lock_sock(sk) in packet_setsockopt when
      changing the packet version while also taking the lock at the start
      of packet_set_ring.
      
      Fixes: f6fb8f10 ("af-packet: TPACKET_V3 flexible buffer implementation.")
      Signed-off-by: default avatarPhilip Pettersson <philip.pettersson@gmail.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      943e7299
    • Thomas Gleixner's avatar
      locking/rtmutex: Prevent dequeue vs. unlock race · b9419575
      Thomas Gleixner authored
      commit dbb26055 upstream.
      
      David reported a futex/rtmutex state corruption. It's caused by the
      following problem:
      
      CPU0		CPU1		CPU2
      
      l->owner=T1
      		rt_mutex_lock(l)
      		lock(l->wait_lock)
      		l->owner = T1 | HAS_WAITERS;
      		enqueue(T2)
      		boost()
      		  unlock(l->wait_lock)
      		schedule()
      
      				rt_mutex_lock(l)
      				lock(l->wait_lock)
      				l->owner = T1 | HAS_WAITERS;
      				enqueue(T3)
      				boost()
      				  unlock(l->wait_lock)
      				schedule()
      		signal(->T2)	signal(->T3)
      		lock(l->wait_lock)
      		dequeue(T2)
      		deboost()
      		  unlock(l->wait_lock)
      				lock(l->wait_lock)
      				dequeue(T3)
      				  ===> wait list is now empty
      				deboost()
      				 unlock(l->wait_lock)
      		lock(l->wait_lock)
      		fixup_rt_mutex_waiters()
      		  if (wait_list_empty(l)) {
      		    owner = l->owner & ~HAS_WAITERS;
      		    l->owner = owner
      		     ==> l->owner = T1
      		  }
      
      				lock(l->wait_lock)
      rt_mutex_unlock(l)		fixup_rt_mutex_waiters()
      				  if (wait_list_empty(l)) {
      				    owner = l->owner & ~HAS_WAITERS;
      cmpxchg(l->owner, T1, NULL)
       ===> Success (l->owner = NULL)
      				    l->owner = owner
      				     ==> l->owner = T1
      				  }
      
      That means the problem is caused by fixup_rt_mutex_waiters() which does the
      RMW to clear the waiters bit unconditionally when there are no waiters in
      the rtmutexes rbtree.
      
      This can be fatal: A concurrent unlock can release the rtmutex in the
      fastpath because the waiters bit is not set. If the cmpxchg() gets in the
      middle of the RMW operation then the previous owner, which just unlocked
      the rtmutex is set as the owner again when the write takes place after the
      successfull cmpxchg().
      
      The solution is rather trivial: verify that the owner member of the rtmutex
      has the waiters bit set before clearing it. This does not require a
      cmpxchg() or other atomic operations because the waiters bit can only be
      set and cleared with the rtmutex wait_lock held. It's also safe against the
      fast path unlock attempt. The unlock attempt via cmpxchg() will either see
      the bit set and take the slowpath or see the bit cleared and release it
      atomically in the fastpath.
      
      It's remarkable that the test program provided by David triggers on ARM64
      and MIPS64 really quick, but it refuses to reproduce on x86-64, while the
      problem exists there as well. That refusal might explain that this got not
      discovered earlier despite the bug existing from day one of the rtmutex
      implementation more than 10 years ago.
      
      Thanks to David for meticulously instrumenting the code and providing the
      information which allowed to decode this subtle problem.
      Reported-by: default avatarDavid Daney <ddaney@caviumnetworks.com>
      Tested-by: default avatarDavid Daney <david.daney@cavium.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Acked-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Sebastian Siewior <bigeasy@linutronix.de>
      Cc: Will Deacon <will.deacon@arm.com>
      Fixes: 23f78d4a ("[PATCH] pi-futex: rt mutex core")
      Link: http://lkml.kernel.org/r/20161130210030.351136722@linutronix.deSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      [bwh: Backported to 3.16: use ACCESS_ONCE() instead of {READ,WRITE}_ONCE()]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      b9419575
    • Sven Eckelmann's avatar
      batman-adv: Check for alloc errors when preparing TT local data · 907742aa
      Sven Eckelmann authored
      commit c2d0f48a upstream.
      
      batadv_tt_prepare_tvlv_local_data can fail to allocate the memory for the
      new TVLV block. The caller is informed about this problem with the returned
      length of 0. Not checking this value results in an invalid memory access
      when either tt_data or tt_change is accessed.
      Reported-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Fixes: 7ea7b4a1 ("batman-adv: make the TT CRC logic VLAN specific")
      Signed-off-by: default avatarSven Eckelmann <sven@narfation.org>
      Signed-off-by: default avatarSimon Wunderlich <sw@simonwunderlich.de>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      907742aa
    • Andrew Donnellan's avatar
      powerpc/eeh: Fix deadlock when PE frozen state can't be cleared · 1344f5b6
      Andrew Donnellan authored
      commit 409bf7f8 upstream.
      
      In eeh_reset_device(), we take the pci_rescan_remove_lock immediately after
      after we call eeh_reset_pe() to reset the PCI controller. We then call
      eeh_clear_pe_frozen_state(), which can return an error. In this case, we
      bail out of eeh_reset_device() without calling pci_unlock_rescan_remove().
      
      Add a call to pci_unlock_rescan_remove() in the eeh_clear_pe_frozen_state()
      error path so that we don't cause a deadlock later on.
      Reported-by: default avatarPradipta Ghosh <pradghos@in.ibm.com>
      Fixes: 78954700 ("powerpc/eeh: Avoid I/O access during PE reset")
      Signed-off-by: default avatarAndrew Donnellan <andrew.donnellan@au1.ibm.com>
      Acked-by: default avatarRussell Currey <ruscur@russell.cc>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      1344f5b6
    • Hongxu Jia's avatar
      netfilter: arp_tables: fix invoking 32bit "iptable -P INPUT ACCEPT" failed in 64bit kernel · 85dc53fe
      Hongxu Jia authored
      commit 17a49cd5 upstream.
      
      Since 09d96860 ("netfilter: x_tables: do compat validation via
      translate_table"), it used compatr structure to assign newinfo
      structure.  In translate_compat_table of ip_tables.c and ip6_tables.c,
      it used compatr->hook_entry to replace info->hook_entry and
      compatr->underflow to replace info->underflow, but not do the same
      replacement in arp_tables.c.
      
      It caused invoking 32-bit "arptbale -P INPUT ACCEPT" failed in 64bit
      kernel.
      --------------------------------------
      root@qemux86-64:~# arptables -P INPUT ACCEPT
      root@qemux86-64:~# arptables -P INPUT ACCEPT
      ERROR: Policy for `INPUT' offset 448 != underflow 0
      arptables: Incompatible with this kernel
      --------------------------------------
      
      Fixes: 09d96860 ("netfilter: x_tables: do compat validation via translate_table")
      Signed-off-by: default avatarHongxu Jia <hongxu.jia@windriver.com>
      Acked-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      85dc53fe
    • Johan Hovold's avatar
      pwm: Fix device reference leak · 61c64c67
      Johan Hovold authored
      commit 0e1614ac upstream.
      
      Make sure to drop the reference to the parent device taken by
      class_find_device() after "unexporting" any children when deregistering
      a PWM chip.
      
      Fixes: 0733424c ("pwm: Unexport children before chip removal")
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarThierry Reding <thierry.reding@gmail.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      61c64c67
    • Jack Morgenstein's avatar
      net/mlx4: Fix uninitialized fields in rule when adding promiscuous mode to... · 96239ede
      Jack Morgenstein authored
      net/mlx4: Fix uninitialized fields in rule when adding promiscuous mode to device managed flow steering
      
      commit 44b911e7 upstream.
      
      In procedure mlx4_flow_steer_promisc_add(), several fields
      were left uninitialized in the rule structure.
      Correctly initialize these fields.
      
      Fixes: 592e49dd ("net/mlx4: Implement promiscuous mode with device managed flow-steering")
      Signed-off-by: default avatarJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: default avatarTariq Toukan <tariqt@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      96239ede
    • Andrew Lunn's avatar
      net: ethernet: mvneta: Remove IFF_UNICAST_FLT which is not implemented · 26f2b33f
      Andrew Lunn authored
      commit 97db8afa upstream.
      
      The mvneta driver advertises it supports IFF_UNICAST_FLT. However, it
      actually does not. The hardware probably does support it, but there is
      no code to configure the filter. As a quick and simple fix, remove the
      flag. This will cause the core to fall back to promiscuous mode.
      Signed-off-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Fixes: b50b72de ("net: mvneta: enable features before registering the driver")
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      26f2b33f
    • John David Anglin's avatar
      parisc: Also flush data TLB in flush_icache_page_asm · 3136a9a1
      John David Anglin authored
      commit 5035b230 upstream.
      
      This is the second issue I noticed in reviewing the parisc TLB code.
      
      The fic instruction may use either the instruction or data TLB in
      flushing the instruction cache.  Thus, on machines with a split TLB, we
      should also flush the data TLB after setting up the temporary alias
      registers.
      
      Although this has no functional impact, I changed the pdtlb and pitlb
      instructions to consistently use the index register %r0.  These
      instructions do not support integer displacements.
      
      Tested on rp3440 and c8000.
      Signed-off-by: default avatarJohn David Anglin  <dave.anglin@bell.net>
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      3136a9a1
    • John David Anglin's avatar
      parisc: Fix race in pci-dma.c · c2bf3d85
      John David Anglin authored
      commit c0452fb9 upstream.
      
      We are still troubled by occasional random segmentation faults and
      memory memory corruption on SMP machines.  The causes quite a few
      package builds to fail on the Debian buildd machines for parisc.  When
      gcc-6 failed to build three times in a row, I looked again at the TLB
      related code.  I found a couple of issues.  This is the first.
      
      In general, we need to ensure page table updates and corresponding TLB
      purges are atomic.  The attached patch fixes an instance in pci-dma.c
      where the page table update was not guarded by the TLB lock.
      
      Tested on rp3440 and c8000.  So far, no further random segmentation
      faults have been observed.
      Signed-off-by: default avatarJohn David Anglin  <dave.anglin@bell.net>
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      c2bf3d85
    • Andrey Ryabinin's avatar
      mpi: Fix NULL ptr dereference in mpi_powm() [ver #3] · 0a74b364
      Andrey Ryabinin authored
      commit f5527fff upstream.
      
      This fixes CVE-2016-8650.
      
      If mpi_powm() is given a zero exponent, it wants to immediately return
      either 1 or 0, depending on the modulus.  However, if the result was
      initalised with zero limb space, no limbs space is allocated and a
      NULL-pointer exception ensues.
      
      Fix this by allocating a minimal amount of limb space for the result when
      the 0-exponent case when the result is 1 and not touching the limb space
      when the result is 0.
      
      This affects the use of RSA keys and X.509 certificates that carry them.
      
      BUG: unable to handle kernel NULL pointer dereference at           (null)
      IP: [<ffffffff8138ce5d>] mpi_powm+0x32/0x7e6
      PGD 0
      Oops: 0002 [#1] SMP
      Modules linked in:
      CPU: 3 PID: 3014 Comm: keyctl Not tainted 4.9.0-rc6-fscache+ #278
      Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014
      task: ffff8804011944c0 task.stack: ffff880401294000
      RIP: 0010:[<ffffffff8138ce5d>]  [<ffffffff8138ce5d>] mpi_powm+0x32/0x7e6
      RSP: 0018:ffff880401297ad8  EFLAGS: 00010212
      RAX: 0000000000000000 RBX: ffff88040868bec0 RCX: ffff88040868bba0
      RDX: ffff88040868b260 RSI: ffff88040868bec0 RDI: ffff88040868bee0
      RBP: ffff880401297ba8 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000047 R11: ffffffff8183b210 R12: 0000000000000000
      R13: ffff8804087c7600 R14: 000000000000001f R15: ffff880401297c50
      FS:  00007f7a7918c700(0000) GS:ffff88041fb80000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000000000000 CR3: 0000000401250000 CR4: 00000000001406e0
      Stack:
       ffff88040868bec0 0000000000000020 ffff880401297b00 ffffffff81376cd4
       0000000000000100 ffff880401297b10 ffffffff81376d12 ffff880401297b30
       ffffffff81376f37 0000000000000100 0000000000000000 ffff880401297ba8
      Call Trace:
       [<ffffffff81376cd4>] ? __sg_page_iter_next+0x43/0x66
       [<ffffffff81376d12>] ? sg_miter_get_next_page+0x1b/0x5d
       [<ffffffff81376f37>] ? sg_miter_next+0x17/0xbd
       [<ffffffff8138ba3a>] ? mpi_read_raw_from_sgl+0xf2/0x146
       [<ffffffff8132a95c>] rsa_verify+0x9d/0xee
       [<ffffffff8132acca>] ? pkcs1pad_sg_set_buf+0x2e/0xbb
       [<ffffffff8132af40>] pkcs1pad_verify+0xc0/0xe1
       [<ffffffff8133cb5e>] public_key_verify_signature+0x1b0/0x228
       [<ffffffff8133d974>] x509_check_for_self_signed+0xa1/0xc4
       [<ffffffff8133cdde>] x509_cert_parse+0x167/0x1a1
       [<ffffffff8133d609>] x509_key_preparse+0x21/0x1a1
       [<ffffffff8133c3d7>] asymmetric_key_preparse+0x34/0x61
       [<ffffffff812fc9f3>] key_create_or_update+0x145/0x399
       [<ffffffff812fe227>] SyS_add_key+0x154/0x19e
       [<ffffffff81001c2b>] do_syscall_64+0x80/0x191
       [<ffffffff816825e4>] entry_SYSCALL64_slow_path+0x25/0x25
      Code: 56 41 55 41 54 53 48 81 ec a8 00 00 00 44 8b 71 04 8b 42 04 4c 8b 67 18 45 85 f6 89 45 80 0f 84 b4 06 00 00 85 c0 75 2f 41 ff ce <49> c7 04 24 01 00 00 00 b0 01 75 0b 48 8b 41 18 48 83 38 01 0f
      RIP  [<ffffffff8138ce5d>] mpi_powm+0x32/0x7e6
       RSP <ffff880401297ad8>
      CR2: 0000000000000000
      ---[ end trace d82015255d4a5d8d ]---
      
      Basically, this is a backport of a libgcrypt patch:
      
      	http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=patch;h=6e1adb05d290aeeb1c230c763970695f4a538526
      
      Fixes: cdec9cb5 ("crypto: GnuPG based MPI lib - source files (part 1)")
      Signed-off-by: default avatarAndrey Ryabinin <aryabinin@virtuozzo.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      cc: Dmitry Kasatkin <dmitry.kasatkin@gmail.com>
      cc: linux-ima-devel@lists.sourceforge.net
      Signed-off-by: default avatarJames Morris <james.l.morris@oracle.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      0a74b364
    • Radim Krčmář's avatar
      KVM: x86: drop error recovery in em_jmp_far and em_ret_far · 4fa681dc
      Radim Krčmář authored
      commit 2117d539 upstream.
      
      em_jmp_far and em_ret_far assumed that setting IP can only fail in 64
      bit mode, but syzkaller proved otherwise (and SDM agrees).
      Code segment was restored upon failure, but it was left uninitialized
      outside of long mode, which could lead to a leak of host kernel stack.
      We could have fixed that by always saving and restoring the CS, but we
      take a simpler approach and just break any guest that manages to fail
      as the error recovery is error-prone and modern CPUs don't need emulator
      for this.
      
      Found by syzkaller:
      
        WARNING: CPU: 2 PID: 3668 at arch/x86/kvm/emulate.c:2217 em_ret_far+0x428/0x480
        Kernel panic - not syncing: panic_on_warn set ...
      
        CPU: 2 PID: 3668 Comm: syz-executor Not tainted 4.9.0-rc4+ #49
        Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
         [...]
        Call Trace:
         [...] __dump_stack lib/dump_stack.c:15
         [...] dump_stack+0xb3/0x118 lib/dump_stack.c:51
         [...] panic+0x1b7/0x3a3 kernel/panic.c:179
         [...] __warn+0x1c4/0x1e0 kernel/panic.c:542
         [...] warn_slowpath_null+0x2c/0x40 kernel/panic.c:585
         [...] em_ret_far+0x428/0x480 arch/x86/kvm/emulate.c:2217
         [...] em_ret_far_imm+0x17/0x70 arch/x86/kvm/emulate.c:2227
         [...] x86_emulate_insn+0x87a/0x3730 arch/x86/kvm/emulate.c:5294
         [...] x86_emulate_instruction+0x520/0x1ba0 arch/x86/kvm/x86.c:5545
         [...] emulate_instruction arch/x86/include/asm/kvm_host.h:1116
         [...] complete_emulated_io arch/x86/kvm/x86.c:6870
         [...] complete_emulated_mmio+0x4e9/0x710 arch/x86/kvm/x86.c:6934
         [...] kvm_arch_vcpu_ioctl_run+0x3b7a/0x5a90 arch/x86/kvm/x86.c:6978
         [...] kvm_vcpu_ioctl+0x61e/0xdd0 arch/x86/kvm/../../../virt/kvm/kvm_main.c:2557
         [...] vfs_ioctl fs/ioctl.c:43
         [...] do_vfs_ioctl+0x18c/0x1040 fs/ioctl.c:679
         [...] SYSC_ioctl fs/ioctl.c:694
         [...] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:685
         [...] entry_SYSCALL_64_fastpath+0x1f/0xc2
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Fixes: d1442d85 ("KVM: x86: Handle errors when RIP is set during far jumps")
      Signed-off-by: default avatarRadim Krčmář <rkrcmar@redhat.com>
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      4fa681dc
    • Dan Carpenter's avatar
      x86/apic/uv: Silence a shift wrapping warning · 8b6e9077
      Dan Carpenter authored
      commit c4597fd7 upstream.
      
      'm_io' is stored in 6 bits so it's a number in the 0-63 range.  Static
      analysis tools complain that 1 << 63 will wrap so I have changed it to
      1ULL << m_io.
      
      This code is over three years old so presumably the bug doesn't happen
      very frequently in real life or someone would have complained by now.
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Cc: Alex Thorlton <athorlton@sgi.com>
      Cc: Dimitri Sivanich <sivanich@sgi.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mike Travis <travis@sgi.com>
      Cc: Nathan Zimmer <nzimmer@sgi.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: kernel-janitors@vger.kernel.org
      Fixes: b15cc4a1 ("x86, uv, uv3: Update x2apic Support for SGI UV3")
      Link: http://lkml.kernel.org/r/20161123221908.GA23997@mwandaSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      8b6e9077
    • Takashi Iwai's avatar
      xc2028: Fix use-after-free bug properly · b8052d28
      Takashi Iwai authored
      commit 22a1e778 upstream.
      
      The commit 8dfbcc43 ("[media] xc2028: avoid use after free") tried
      to address the reported use-after-free by clearing the reference.
      
      However, it's clearing the wrong pointer; it sets NULL to
      priv->ctrl.fname, but it's anyway overwritten by the next line
      memcpy(&priv->ctrl, p, sizeof(priv->ctrl)).
      
      OTOH, the actual code accessing the freed string is the strcmp() call
      with priv->fname:
      	if (!firmware_name[0] && p->fname &&
      	    priv->fname && strcmp(p->fname, priv->fname))
      		free_firmware(priv);
      
      where priv->fname points to the previous file name, and this was
      already freed by kfree().
      
      For fixing the bug properly, this patch does the following:
      
      - Keep the copy of firmware file name in only priv->fname,
        priv->ctrl.fname isn't changed;
      - The allocation is done only when the firmware gets loaded;
      - The kfree() is called in free_firmware() commonly
      
      Fixes: commit 8dfbcc43 ('[media] xc2028: avoid use after free')
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      b8052d28
    • Chris Metcalf's avatar
      tile: avoid using clocksource_cyc2ns with absolute cycle count · b3a20f6b
      Chris Metcalf authored
      commit e658a6f1 upstream.
      
      For large values of "mult" and long uptimes, the intermediate
      result of "cycles * mult" can overflow 64 bits.  For example,
      the tile platform calls clocksource_cyc2ns with a 1.2 GHz clock;
      we have mult = 853, and after 208.5 days, we overflow 64 bits.
      
      Since clocksource_cyc2ns() is intended to be used for relative
      cycle counts, not absolute cycle counts, performance is more
      importance than accepting a wider range of cycle values.  So,
      just use mult_frac() directly in tile's sched_clock().
      
      Commit 4cecf6d4 ("sched, x86: Avoid unnecessary overflow
      in sched_clock") by Salman Qazi results in essentially the same
      generated code for x86 as this change does for tile.  In fact,
      a follow-on change by Salman introduced mult_frac() and switched
      to using it, so the C code was largely identical at that point too.
      
      Peter Zijlstra then added mul_u64_u32_shr() and switched x86
      to use it.  This is, in principle, better; by optimizing the
      64x64->64 multiplies to be 32x32->64 multiplies we can potentially
      save some time.  However, the compiler piplines the 64x64->64
      multiplies pretty well, and the conditional branch in the generic
      mul_u64_u32_shr() causes some bubbles in execution, with the
      result that it's pretty much a wash.  If tilegx provided its own
      implementation of mul_u64_u32_shr() without the conditional branch,
      we could potentially save 3 cycles, but that seems like small gain
      for a fair amount of additional build scaffolding; no other platform
      currently provides a mul_u64_u32_shr() override, and tile doesn't
      currently have an <asm/div64.h> header to put the override in.
      
      Additionally, gcc currently has an optimization bug that prevents
      it from recognizing the opportunity to use a 32x32->64 multiply,
      and so the result would be no better than the existing mult_frac()
      until such time as the compiler is fixed.
      
      For now, just using mult_frac() seems like the right answer.
      Signed-off-by: default avatarChris Metcalf <cmetcalf@mellanox.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      b3a20f6b
    • Andy Lutomirski's avatar
      x86/traps: Ignore high word of regs->cs in early_fixup_exception() · 7781dcac
      Andy Lutomirski authored
      commit fc0e81b2 upstream.
      
      On the 80486 DX, it seems that some exceptions may leave garbage in
      the high bits of CS.  This causes sporadic failures in which
      early_fixup_exception() refuses to fix up an exception.
      
      As far as I can tell, this has been buggy for a long time, but the
      problem seems to have been exacerbated by commits:
      
        1e02ce4c ("x86: Store a per-cpu shadow copy of CR4")
        e1bfc11c ("x86/init: Fix cr4_init_shadow() on CR4-less machines")
      
      This appears to have broken for as long as we've had early
      exception handling.
      
      [ This backport should apply to kernels from 3.4 - 4.5. ]
      
      Fixes: 4c5023a3 ("x86-32: Handle exception table entries during early boot")
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: stable@vger.kernel.org
      Reported-by: default avatarMatthew Whitehead <tedheadster@gmail.com>
      Signed-off-by: default avatarAndy Lutomirski <luto@kernel.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      7781dcac
    • John Johansen's avatar
      apparmor: fix change_hat not finding hat after policy replacement · 31e7f933
      John Johansen authored
      commit 3d40658c upstream.
      
      After a policy replacement, the task cred may be out of date and need
      to be updated. However change_hat is using the stale profiles from
      the out of date cred resulting in either: a stale profile being applied
      or, incorrect failure when searching for a hat profile as it has been
      migrated to the new parent profile.
      
      Fixes: 01e2b670 (failure to find hat)
      Fixes: 898127c3 (stale policy being applied)
      Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1000287Signed-off-by: default avatarJohn Johansen <john.johansen@canonical.com>
      Signed-off-by: default avatarJames Morris <james.l.morris@oracle.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      31e7f933
    • Guillaume Nault's avatar
      l2tp: fix racy SOCK_ZAPPED flag check in l2tp_ip{,6}_bind() · 7c3ad0d8
      Guillaume Nault authored
      commit 32c23116 upstream.
      
      Lock socket before checking the SOCK_ZAPPED flag in l2tp_ip6_bind().
      Without lock, a concurrent call could modify the socket flags between
      the sock_flag(sk, SOCK_ZAPPED) test and the lock_sock() call. This way,
      a socket could be inserted twice in l2tp_ip6_bind_table. Releasing it
      would then leave a stale pointer there, generating use-after-free
      errors when walking through the list or modifying adjacent entries.
      
      BUG: KASAN: use-after-free in l2tp_ip6_close+0x22e/0x290 at addr ffff8800081b0ed8
      Write of size 8 by task syz-executor/10987
      CPU: 0 PID: 10987 Comm: syz-executor Not tainted 4.8.0+ #39
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
       ffff880031d97838 ffffffff829f835b ffff88001b5a1640 ffff8800081b0ec0
       ffff8800081b15a0 ffff8800081b6d20 ffff880031d97860 ffffffff8174d3cc
       ffff880031d978f0 ffff8800081b0e80 ffff88001b5a1640 ffff880031d978e0
      Call Trace:
       [<ffffffff829f835b>] dump_stack+0xb3/0x118 lib/dump_stack.c:15
       [<ffffffff8174d3cc>] kasan_object_err+0x1c/0x70 mm/kasan/report.c:156
       [<     inline     >] print_address_description mm/kasan/report.c:194
       [<ffffffff8174d666>] kasan_report_error+0x1f6/0x4d0 mm/kasan/report.c:283
       [<     inline     >] kasan_report mm/kasan/report.c:303
       [<ffffffff8174db7e>] __asan_report_store8_noabort+0x3e/0x40 mm/kasan/report.c:329
       [<     inline     >] __write_once_size ./include/linux/compiler.h:249
       [<     inline     >] __hlist_del ./include/linux/list.h:622
       [<     inline     >] hlist_del_init ./include/linux/list.h:637
       [<ffffffff8579047e>] l2tp_ip6_close+0x22e/0x290 net/l2tp/l2tp_ip6.c:239
       [<ffffffff850b2dfd>] inet_release+0xed/0x1c0 net/ipv4/af_inet.c:415
       [<ffffffff851dc5a0>] inet6_release+0x50/0x70 net/ipv6/af_inet6.c:422
       [<ffffffff84c4581d>] sock_release+0x8d/0x1d0 net/socket.c:570
       [<ffffffff84c45976>] sock_close+0x16/0x20 net/socket.c:1017
       [<ffffffff817a108c>] __fput+0x28c/0x780 fs/file_table.c:208
       [<ffffffff817a1605>] ____fput+0x15/0x20 fs/file_table.c:244
       [<ffffffff813774f9>] task_work_run+0xf9/0x170
       [<ffffffff81324aae>] do_exit+0x85e/0x2a00
       [<ffffffff81326dc8>] do_group_exit+0x108/0x330
       [<ffffffff81348cf7>] get_signal+0x617/0x17a0 kernel/signal.c:2307
       [<ffffffff811b49af>] do_signal+0x7f/0x18f0
       [<ffffffff810039bf>] exit_to_usermode_loop+0xbf/0x150 arch/x86/entry/common.c:156
       [<     inline     >] prepare_exit_to_usermode arch/x86/entry/common.c:190
       [<ffffffff81006060>] syscall_return_slowpath+0x1a0/0x1e0 arch/x86/entry/common.c:259
       [<ffffffff85e4d726>] entry_SYSCALL_64_fastpath+0xc4/0xc6
      Object at ffff8800081b0ec0, in cache L2TP/IPv6 size: 1448
      Allocated:
      PID = 10987
       [ 1116.897025] [<ffffffff811ddcb6>] save_stack_trace+0x16/0x20
       [ 1116.897025] [<ffffffff8174c736>] save_stack+0x46/0xd0
       [ 1116.897025] [<ffffffff8174c9ad>] kasan_kmalloc+0xad/0xe0
       [ 1116.897025] [<ffffffff8174cee2>] kasan_slab_alloc+0x12/0x20
       [ 1116.897025] [<     inline     >] slab_post_alloc_hook mm/slab.h:417
       [ 1116.897025] [<     inline     >] slab_alloc_node mm/slub.c:2708
       [ 1116.897025] [<     inline     >] slab_alloc mm/slub.c:2716
       [ 1116.897025] [<ffffffff817476a8>] kmem_cache_alloc+0xc8/0x2b0 mm/slub.c:2721
       [ 1116.897025] [<ffffffff84c4f6a9>] sk_prot_alloc+0x69/0x2b0 net/core/sock.c:1326
       [ 1116.897025] [<ffffffff84c58ac8>] sk_alloc+0x38/0xae0 net/core/sock.c:1388
       [ 1116.897025] [<ffffffff851ddf67>] inet6_create+0x2d7/0x1000 net/ipv6/af_inet6.c:182
       [ 1116.897025] [<ffffffff84c4af7b>] __sock_create+0x37b/0x640 net/socket.c:1153
       [ 1116.897025] [<     inline     >] sock_create net/socket.c:1193
       [ 1116.897025] [<     inline     >] SYSC_socket net/socket.c:1223
       [ 1116.897025] [<ffffffff84c4b46f>] SyS_socket+0xef/0x1b0 net/socket.c:1203
       [ 1116.897025] [<ffffffff85e4d685>] entry_SYSCALL_64_fastpath+0x23/0xc6
      Freed:
      PID = 10987
       [ 1116.897025] [<ffffffff811ddcb6>] save_stack_trace+0x16/0x20
       [ 1116.897025] [<ffffffff8174c736>] save_stack+0x46/0xd0
       [ 1116.897025] [<ffffffff8174cf61>] kasan_slab_free+0x71/0xb0
       [ 1116.897025] [<     inline     >] slab_free_hook mm/slub.c:1352
       [ 1116.897025] [<     inline     >] slab_free_freelist_hook mm/slub.c:1374
       [ 1116.897025] [<     inline     >] slab_free mm/slub.c:2951
       [ 1116.897025] [<ffffffff81748b28>] kmem_cache_free+0xc8/0x330 mm/slub.c:2973
       [ 1116.897025] [<     inline     >] sk_prot_free net/core/sock.c:1369
       [ 1116.897025] [<ffffffff84c541eb>] __sk_destruct+0x32b/0x4f0 net/core/sock.c:1444
       [ 1116.897025] [<ffffffff84c5aca4>] sk_destruct+0x44/0x80 net/core/sock.c:1452
       [ 1116.897025] [<ffffffff84c5ad33>] __sk_free+0x53/0x220 net/core/sock.c:1460
       [ 1116.897025] [<ffffffff84c5af23>] sk_free+0x23/0x30 net/core/sock.c:1471
       [ 1116.897025] [<ffffffff84c5cb6c>] sk_common_release+0x28c/0x3e0 ./include/net/sock.h:1589
       [ 1116.897025] [<ffffffff8579044e>] l2tp_ip6_close+0x1fe/0x290 net/l2tp/l2tp_ip6.c:243
       [ 1116.897025] [<ffffffff850b2dfd>] inet_release+0xed/0x1c0 net/ipv4/af_inet.c:415
       [ 1116.897025] [<ffffffff851dc5a0>] inet6_release+0x50/0x70 net/ipv6/af_inet6.c:422
       [ 1116.897025] [<ffffffff84c4581d>] sock_release+0x8d/0x1d0 net/socket.c:570
       [ 1116.897025] [<ffffffff84c45976>] sock_close+0x16/0x20 net/socket.c:1017
       [ 1116.897025] [<ffffffff817a108c>] __fput+0x28c/0x780 fs/file_table.c:208
       [ 1116.897025] [<ffffffff817a1605>] ____fput+0x15/0x20 fs/file_table.c:244
       [ 1116.897025] [<ffffffff813774f9>] task_work_run+0xf9/0x170
       [ 1116.897025] [<ffffffff81324aae>] do_exit+0x85e/0x2a00
       [ 1116.897025] [<ffffffff81326dc8>] do_group_exit+0x108/0x330
       [ 1116.897025] [<ffffffff81348cf7>] get_signal+0x617/0x17a0 kernel/signal.c:2307
       [ 1116.897025] [<ffffffff811b49af>] do_signal+0x7f/0x18f0
       [ 1116.897025] [<ffffffff810039bf>] exit_to_usermode_loop+0xbf/0x150 arch/x86/entry/common.c:156
       [ 1116.897025] [<     inline     >] prepare_exit_to_usermode arch/x86/entry/common.c:190
       [ 1116.897025] [<ffffffff81006060>] syscall_return_slowpath+0x1a0/0x1e0 arch/x86/entry/common.c:259
       [ 1116.897025] [<ffffffff85e4d726>] entry_SYSCALL_64_fastpath+0xc4/0xc6
      Memory state around the buggy address:
       ffff8800081b0d80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
       ffff8800081b0e00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      >ffff8800081b0e80: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
                                                          ^
       ffff8800081b0f00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff8800081b0f80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      
      ==================================================================
      
      The same issue exists with l2tp_ip_bind() and l2tp_ip_bind_table.
      
      Fixes: c51ce497 ("l2tp: fix oops in L2TP IP sockets for connect() AF_UNSPEC case")
      Reported-by: default avatarBaozeng Ding <sploving1@gmail.com>
      Reported-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Tested-by: default avatarBaozeng Ding <sploving1@gmail.com>
      Signed-off-by: default avatarGuillaume Nault <g.nault@alphalink.fr>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      7c3ad0d8
    • Theodore Ts'o's avatar
      ext4: sanity check the block and cluster size at mount time · 304ad3c9
      Theodore Ts'o authored
      commit 8cdf3372 upstream.
      
      If the block size or cluster size is insane, reject the mount.  This
      is important for security reasons (although we shouldn't be just
      depending on this check).
      
      Ref: http://www.securityfocus.com/archive/1/539661
      Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1332506Reported-by: default avatarBorislav Petkov <bp@alien8.de>
      Reported-by: default avatarNikolay Borisov <kernel@kyup.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      304ad3c9
    • Paolo Bonzini's avatar
      KVM: x86: fix missed SRCU usage in kvm_lapic_set_vapic_addr · 2156e86c
      Paolo Bonzini authored
      commit 7301d6ab upstream.
      
      Reported by syzkaller:
      
          [ INFO: suspicious RCU usage. ]
          4.9.0-rc4+ #47 Not tainted
          -------------------------------
          ./include/linux/kvm_host.h:536 suspicious rcu_dereference_check() usage!
      
          stack backtrace:
          CPU: 1 PID: 6679 Comm: syz-executor Not tainted 4.9.0-rc4+ #47
          Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
           ffff880039e2f6d0 ffffffff81c2e46b ffff88003e3a5b40 0000000000000000
           0000000000000001 ffffffff83215600 ffff880039e2f700 ffffffff81334ea9
           ffffc9000730b000 0000000000000004 ffff88003c4f8420 ffff88003d3f8000
          Call Trace:
           [<     inline     >] __dump_stack lib/dump_stack.c:15
           [<ffffffff81c2e46b>] dump_stack+0xb3/0x118 lib/dump_stack.c:51
           [<ffffffff81334ea9>] lockdep_rcu_suspicious+0x139/0x180 kernel/locking/lockdep.c:4445
           [<     inline     >] __kvm_memslots include/linux/kvm_host.h:534
           [<     inline     >] kvm_memslots include/linux/kvm_host.h:541
           [<ffffffff8105d6ae>] kvm_gfn_to_hva_cache_init+0xa1e/0xce0 virt/kvm/kvm_main.c:1941
           [<ffffffff8112685d>] kvm_lapic_set_vapic_addr+0xed/0x140 arch/x86/kvm/lapic.c:2217
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Fixes: fda4e2e8
      Cc: Andrew Honig <ahonig@google.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Reviewed-by: default avatarDavid Hildenbrand <david@redhat.com>
      Signed-off-by: default avatarRadim Krčmář <rkrcmar@redhat.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      2156e86c
    • Ignacio Alvarado's avatar
      KVM: Disable irq while unregistering user notifier · b3674a17
      Ignacio Alvarado authored
      commit 1650b4eb upstream.
      
      Function user_notifier_unregister should be called only once for each
      registered user notifier.
      
      Function kvm_arch_hardware_disable can be executed from an IPI context
      which could cause a race condition with a VCPU returning to user mode
      and attempting to unregister the notifier.
      Signed-off-by: default avatarIgnacio Alvarado <ikalvarado@google.com>
      Fixes: 18863bdd ("KVM: x86 shared msr infrastructure")
      Reviewed-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarRadim Krčmář <rkrcmar@redhat.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      b3674a17
    • Johan Hovold's avatar
      net: ethernet: ti: cpsw: fix secondary-emac probe error path · 8b4edf66
      Johan Hovold authored
      commit a7fe9d46 upstream.
      
      Make sure to deregister the primary device in case the secondary emac
      fails to probe.
      
      kernel BUG at /home/johan/work/omicron/src/linux/net/core/dev.c:7743!
      ...
      [<c05b3dec>] (free_netdev) from [<c04fe6c0>] (cpsw_probe+0x9cc/0xe50)
      [<c04fe6c0>] (cpsw_probe) from [<c047b28c>] (platform_drv_probe+0x5c/0xc0)
      
      Fixes: d9ba8f9e ("driver: net: ethernet: cpsw: dual emac interface
      implementation")
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      8b4edf66
    • Johan Hovold's avatar
      net: ethernet: ti: cpsw: fix mdio device reference leak · 0b19869e
      Johan Hovold authored
      commit 86e1d5ad upstream.
      
      Make sure to drop the reference taken by of_find_device_by_node() when
      looking up an mdio device from a phy_id property during probe.
      
      Fixes: 549985ee ("cpsw: simplify the setup of the register
      pointers")
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [bwh: Backported to 3.16: adjust context, indentation]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      0b19869e
    • Johan Hovold's avatar
      net: ethernet: ti: cpsw: fix bad register access in probe error path · b50bf102
      Johan Hovold authored
      commit c46ab7e0 upstream.
      
      Make sure to keep the platform device runtime-resumed throughout probe
      to avoid accessing the CPSW registers in the error path (e.g. for
      deferred probe) with clocks disabled:
      
      Unhandled fault: external abort on non-linefetch (0x1008) at 0xd0872d08
      ...
      [<c04fabcc>] (cpsw_ale_control_set) from [<c04fb8b4>] (cpsw_ale_destroy+0x2c/0x44)
      [<c04fb8b4>] (cpsw_ale_destroy) from [<c04fea58>] (cpsw_probe+0xbd0/0x10c4)
      [<c04fea58>] (cpsw_probe) from [<c047b2a0>] (platform_drv_probe+0x5c/0xc0)
      
      Fixes: df828598 ("netdev: driver: ethernet: Add TI CPSW driver")
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [bwh: Backported to 3.16:
       - s/cpsw->/priv->/g
       - Adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      b50bf102
    • Johannes Berg's avatar
      cfg80211: limit scan results cache size · a78748b4
      Johannes Berg authored
      commit 9853a55e upstream.
      
      It's possible to make scanning consume almost arbitrary amounts
      of memory, e.g. by sending beacon frames with random BSSIDs at
      high rates while somebody is scanning.
      
      Limit the number of BSS table entries we're willing to cache to
      1000, limiting maximum memory usage to maybe 4-5MB, but lower
      in practice - that would be the case for having both full-sized
      beacon and probe response frames for each entry; this seems not
      possible in practice, so a limit of 1000 entries will likely be
      closer to 0.5 MB.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      a78748b4
    • Johan Hovold's avatar
      of_mdio: fix node leak in of_phy_register_fixed_link error path · b2486d4f
      Johan Hovold authored
      commit 48c1699d upstream.
      
      Make sure to drop the of_node reference also on failure to parse the
      speed property in of_phy_register_fixed_link().
      
      Fixes: 3be2a49e ("of: provide a binding for fixed link PHYs")
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      b2486d4f
    • Brian Norris's avatar
      mwifiex: printk() overflow with 32-byte SSIDs · dddd478f
      Brian Norris authored
      commit fcd2042e upstream.
      
      SSIDs aren't guaranteed to be 0-terminated. Let's cap the max length
      when we print them out.
      
      This can be easily noticed by connecting to a network with a 32-octet
      SSID:
      
      [ 3903.502925] mwifiex_pcie 0000:01:00.0: info: trying to associate to
      '0123456789abcdef0123456789abcdef <uninitialized mem>' bssid
      xx:xx:xx:xx:xx:xx
      
      Fixes: 5e6e3a92 ("wireless: mwifiex: initial commit for Marvell mwifiex driver")
      Signed-off-by: default avatarBrian Norris <briannorris@chromium.org>
      Acked-by: default avatarAmitkumar Karwar <akarwar@marvell.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      [bwh: Backported to 3.16: adjust filename]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      dddd478f
    • Matan Barak's avatar
      IB/mlx4: Fix create CQ error flow · 52e8b41f
      Matan Barak authored
      commit 593ff73b upstream.
      
      Currently, if ib_copy_to_udata fails, the CQ
      won't be deleted from the radix tree and the HW (HW2SW).
      
      Fixes: 225c7b1f ('IB/mlx4: Add a driver Mellanox ConnectX InfiniBand adapters')
      Signed-off-by: default avatarMatan Barak <matanb@mellanox.com>
      Signed-off-by: default avatarDaniel Jurgens <danielj@mellanox.com>
      Reviewed-by: default avatarMark Bloch <markb@mellanox.com>
      Signed-off-by: default avatarLeon Romanovsky <leon@kernel.org>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      52e8b41f
    • Eli Cohen's avatar
      IB/mlx5: Fix NULL pointer dereference on debug print · b959798f
      Eli Cohen authored
      commit a1ab8402 upstream.
      
      For XRC QP CQs may not exist. Check before attempting dereference.
      
      Fixes: e126ba97 ('mlx5: Add driver for Mellanox Connect-IB adapters')
      Signed-off-by: default avatarEli Cohen <eli@mellanox.com>
      Signed-off-by: default avatarMaor Gottlieb <maorg@mellanox.com>
      Reviewed-by: default avatarYishai Hadas <yishaih@mellanox.com>
      Signed-off-by: default avatarLeon Romanovsky <leon@kernel.org>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      b959798f
    • Moshe Lazer's avatar
      IB/mlx5: Resolve soft lock on massive reg MRs · 0d4ad2aa
      Moshe Lazer authored
      commit 6bc1a656 upstream.
      
      When calling reg_mr of large MRs (e.g. 4GB) from multiple processes
      and MR caches can't supply the required amount of MRs the slow-path
      of MR allocation may be used. In this case we need to serialize the
      slow-path between the processes to avoid soft lock.
      
      Fixes: e126ba97 ('mlx5: Add driver for Mellanox Connect-IB adapters')
      Signed-off-by: default avatarMoshe Lazer <moshel@mellanox.com>
      Signed-off-by: default avatarMaor Gottlieb <maorg@mellanox.com>
      Reviewed-by: default avatarEli Cohen <eli@mellanox.com>
      Signed-off-by: default avatarLeon Romanovsky <leon@kernel.org>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      0d4ad2aa
    • Daniel Jurgens's avatar
      IB/mlx5: Use cache line size to select CQE stride · 765316af
      Daniel Jurgens authored
      commit 16b0e069 upstream.
      
      When creating kernel CQs use 128B CQE stride if the
      cache line size is 128B, 64B otherwise.  This prevents
      multiple CQEs from residing in a 128B cache line,
      which can cause retries when there are concurrent
      read and writes in one cache line.
      
      Tested with IPoIB on PPC64, saw ~5% throughput
      improvement.
      
      Fixes: e126ba97 ('mlx5: Add driver for Mellanox Connect-IB adapters')
      Signed-off-by: default avatarDaniel Jurgens <danielj@mellanox.com>
      Signed-off-by: default avatarMaor Gottlieb <maorg@mellanox.com>
      Signed-off-by: default avatarLeon Romanovsky <leon@kernel.org>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      765316af
    • Mark Bloch's avatar
      IB/core: Avoid unsigned int overflow in sg_alloc_table · d05da7e2
      Mark Bloch authored
      commit 3c7ba576 upstream.
      
      sg_alloc_table gets unsigned int as parameter while the driver
      returns it as size_t. Check npages isn't greater than maximum
      unsigned int.
      
      Fixes: eeb8461e ("IB: Refactor umem to use linear SG table")
      Signed-off-by: default avatarMark Bloch <markb@mellanox.com>
      Signed-off-by: default avatarMaor Gottlieb <maorg@mellanox.com>
      Signed-off-by: default avatarLeon Romanovsky <leon@kernel.org>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      d05da7e2
    • Mark Bloch's avatar
      IB/cm: Mark stale CM id's whenever the mad agent was unregistered · 8ad2c099
      Mark Bloch authored
      commit 9db0ff53 upstream.
      
      When there is a CM id object that has port assigned to it, it means that
      the cm-id asked for the specific port that it should go by it, but if
      that port was removed (hot-unplug event) the cm-id was not updated.
      In order to fix that the port keeps a list of all the cm-id's that are
      planning to go by it, whenever the port is removed it marks all of them
      as invalid.
      
      This commit fixes a kernel panic which happens when running traffic between
      guests and we force reboot a guest mid traffic, it triggers a kernel panic:
      
       Call Trace:
        [<ffffffff815271fa>] ? panic+0xa7/0x16f
        [<ffffffff8152b534>] ? oops_end+0xe4/0x100
        [<ffffffff8104a00b>] ? no_context+0xfb/0x260
        [<ffffffff81084db2>] ? del_timer_sync+0x22/0x30
        [<ffffffff8104a295>] ? __bad_area_nosemaphore+0x125/0x1e0
        [<ffffffff81084240>] ? process_timeout+0x0/0x10
        [<ffffffff8104a363>] ? bad_area_nosemaphore+0x13/0x20
        [<ffffffff8104aabf>] ? __do_page_fault+0x31f/0x480
        [<ffffffff81065df0>] ? default_wake_function+0x0/0x20
        [<ffffffffa0752675>] ? free_msg+0x55/0x70 [mlx5_core]
        [<ffffffffa0753434>] ? cmd_exec+0x124/0x840 [mlx5_core]
        [<ffffffff8105a924>] ? find_busiest_group+0x244/0x9f0
        [<ffffffff8152d45e>] ? do_page_fault+0x3e/0xa0
        [<ffffffff8152a815>] ? page_fault+0x25/0x30
        [<ffffffffa024da25>] ? cm_alloc_msg+0x35/0xc0 [ib_cm]
        [<ffffffffa024e821>] ? ib_send_cm_dreq+0xb1/0x1e0 [ib_cm]
        [<ffffffffa024f836>] ? cm_destroy_id+0x176/0x320 [ib_cm]
        [<ffffffffa024fb00>] ? ib_destroy_cm_id+0x10/0x20 [ib_cm]
        [<ffffffffa034f527>] ? ipoib_cm_free_rx_reap_list+0xa7/0x110 [ib_ipoib]
        [<ffffffffa034f590>] ? ipoib_cm_rx_reap+0x0/0x20 [ib_ipoib]
        [<ffffffffa034f5a5>] ? ipoib_cm_rx_reap+0x15/0x20 [ib_ipoib]
        [<ffffffff81094d20>] ? worker_thread+0x170/0x2a0
        [<ffffffff8109b2a0>] ? autoremove_wake_function+0x0/0x40
        [<ffffffff81094bb0>] ? worker_thread+0x0/0x2a0
        [<ffffffff8109aef6>] ? kthread+0x96/0xa0
        [<ffffffff8100c20a>] ? child_rip+0xa/0x20
        [<ffffffff8109ae60>] ? kthread+0x0/0xa0
        [<ffffffff8100c200>] ? child_rip+0x0/0x20
      
      Fixes: a977049d ("[PATCH] IB: Add the kernel CM implementation")
      Signed-off-by: default avatarMark Bloch <markb@mellanox.com>
      Signed-off-by: default avatarErez Shitrit <erezsh@mellanox.com>
      Reviewed-by: default avatarMaor Gottlieb <maorg@mellanox.com>
      Signed-off-by: default avatarLeon Romanovsky <leon@kernel.org>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      8ad2c099
    • Tariq Toukan's avatar
      IB/uverbs: Fix leak of XRC target QPs · 7bb7d0aa
      Tariq Toukan authored
      commit 5b810a24 upstream.
      
      The real QP is destroyed in case of the ref count reaches zero, but
      for XRC target QPs this call was missed and caused to QP leaks.
      
      Let's call to destroy for all flows.
      
      Fixes: 0e0ec7e0 ('RDMA/core: Export ib_open_qp() to share XRC...')
      Signed-off-by: default avatarTariq Toukan <tariqt@mellanox.com>
      Signed-off-by: default avatarNoa Osherovich <noaos@mellanox.com>
      Signed-off-by: default avatarLeon Romanovsky <leon@kernel.org>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      7bb7d0aa
    • Keith Busch's avatar
      nvme/pci: Don't free queues on error · 4f5af796
      Keith Busch authored
      commit d4875622 upstream.
      
      The nvme_remove function tears down all allocated resources in the correct
      order, so no need to free queues on error during initialization. This
      fixes possible use-after-free errors when queues are still associated
      with a blk-mq hctx.
      Reported-by: default avatarScott Bauer <scott.bauer@intel.com>
      Tested-by: default avatarScott Bauer <scott.bauer@intel.com>
      Signed-off-by: default avatarKeith Busch <keith.busch@intel.com>
      Reviewed-by: default avatarSagi Grimberg <sagi@grimbeg.me>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      [bwh: Backported to 3.16:
       - Adjust filename, context
       - Only nvme_setup_io_queues() needs to be fixed]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      4f5af796
    • Paul Jakma's avatar
      USB: serial: cp210x: add ID for the Zone DPMX · 220d91f7
      Paul Jakma authored
      commit 2ab13292 upstream.
      
      The BRIM Brothers Zone DPMX is a bicycle powermeter. This ID is for the USB
      serial interface in its charging dock for the control pods, via which some
      settings for the pods can be modified.
      Signed-off-by: default avatarPaul Jakma <paul@jakma.org>
      Cc: Barry Redmond <barry@brimbrothers.com>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      220d91f7