1. 08 Apr, 2018 33 commits
  2. 31 Mar, 2018 7 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.9.92 · f080bba2
      Greg Kroah-Hartman authored
      f080bba2
    • Yunsheng Lin's avatar
      net: hns: Fix a skb used after free bug · a8f4be01
      Yunsheng Lin authored
      commit 27463ad9 upstream.
      
      skb maybe freed in hns_nic_net_xmit_hw() and return NETDEV_TX_OK,
      which cause hns_nic_net_xmit to use a freed skb.
      
      BUG: KASAN: use-after-free in hns_nic_net_xmit_hw+0x62c/0x940...
      	[17659.112635]      alloc_debug_processing+0x18c/0x1a0
      	[17659.117208]      __slab_alloc+0x52c/0x560
      	[17659.120909]      kmem_cache_alloc_node+0xac/0x2c0
      	[17659.125309]      __alloc_skb+0x6c/0x260
      	[17659.128837]      tcp_send_ack+0x8c/0x280
      	[17659.132449]      __tcp_ack_snd_check+0x9c/0xf0
      	[17659.136587]      tcp_rcv_established+0x5a4/0xa70
      	[17659.140899]      tcp_v4_do_rcv+0x27c/0x620
      	[17659.144687]      tcp_prequeue_process+0x108/0x170
      	[17659.149085]      tcp_recvmsg+0x940/0x1020
      	[17659.152787]      inet_recvmsg+0x124/0x180
      	[17659.156488]      sock_recvmsg+0x64/0x80
      	[17659.160012]      SyS_recvfrom+0xd8/0x180
      	[17659.163626]      __sys_trace_return+0x0/0x4
      	[17659.167506] INFO: Freed in kfree_skbmem+0xa0/0xb0 age=23 cpu=1 pid=13
      	[17659.174000]      free_debug_processing+0x1d4/0x2c0
      	[17659.178486]      __slab_free+0x240/0x390
      	[17659.182100]      kmem_cache_free+0x24c/0x270
      	[17659.186062]      kfree_skbmem+0xa0/0xb0
      	[17659.189587]      __kfree_skb+0x28/0x40
      	[17659.193025]      napi_gro_receive+0x168/0x1c0
      	[17659.197074]      hns_nic_rx_up_pro+0x58/0x90
      	[17659.201038]      hns_nic_rx_poll_one+0x518/0xbc0
      	[17659.205352]      hns_nic_common_poll+0x94/0x140
      	[17659.209576]      net_rx_action+0x458/0x5e0
      	[17659.213363]      __do_softirq+0x1b8/0x480
      	[17659.217062]      run_ksoftirqd+0x64/0x80
      	[17659.220679]      smpboot_thread_fn+0x224/0x310
      	[17659.224821]      kthread+0x150/0x170
      	[17659.228084]      ret_from_fork+0x10/0x40
      
      	BUG: KASAN: use-after-free in hns_nic_net_xmit+0x8c/0xc0...
      	[17751.080490]      __slab_alloc+0x52c/0x560
      	[17751.084188]      kmem_cache_alloc+0x244/0x280
      	[17751.088238]      __build_skb+0x40/0x150
      	[17751.091764]      build_skb+0x28/0x100
      	[17751.095115]      __alloc_rx_skb+0x94/0x150
      	[17751.098900]      __napi_alloc_skb+0x34/0x90
      	[17751.102776]      hns_nic_rx_poll_one+0x180/0xbc0
      	[17751.107097]      hns_nic_common_poll+0x94/0x140
      	[17751.111333]      net_rx_action+0x458/0x5e0
      	[17751.115123]      __do_softirq+0x1b8/0x480
      	[17751.118823]      run_ksoftirqd+0x64/0x80
      	[17751.122437]      smpboot_thread_fn+0x224/0x310
      	[17751.126575]      kthread+0x150/0x170
      	[17751.129838]      ret_from_fork+0x10/0x40
      	[17751.133454] INFO: Freed in kfree_skbmem+0xa0/0xb0 age=19 cpu=7 pid=43
      	[17751.139951]      free_debug_processing+0x1d4/0x2c0
      	[17751.144436]      __slab_free+0x240/0x390
      	[17751.148051]      kmem_cache_free+0x24c/0x270
      	[17751.152014]      kfree_skbmem+0xa0/0xb0
      	[17751.155543]      __kfree_skb+0x28/0x40
      	[17751.159022]      napi_gro_receive+0x168/0x1c0
      	[17751.163074]      hns_nic_rx_up_pro+0x58/0x90
      	[17751.167041]      hns_nic_rx_poll_one+0x518/0xbc0
      	[17751.171358]      hns_nic_common_poll+0x94/0x140
      	[17751.175585]      net_rx_action+0x458/0x5e0
      	[17751.179373]      __do_softirq+0x1b8/0x480
      	[17751.183076]      run_ksoftirqd+0x64/0x80
      	[17751.186691]      smpboot_thread_fn+0x224/0x310
      	[17751.190826]      kthread+0x150/0x170
      	[17751.194093]      ret_from_fork+0x10/0x40
      
      Fixes: 13ac695e ("net:hns: Add support of Hip06 SoC to the Hislicon Network Subsystem")
      Signed-off-by: default avatarYunsheng Lin <linyunsheng@huawei.com>
      Signed-off-by: default avatarlipeng <lipeng321@huawei.com>
      Reported-by: default avatarJun He <hjat2005@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarErick Reyes <erickreyes@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a8f4be01
    • Tom Herbert's avatar
      kcm: lock lower socket in kcm_attach · 406996f3
      Tom Herbert authored
      
      [ Upstream commit 2cc683e8 ]
      
      Need to lock lower socket in order to provide mutual exclusion
      with kcm_unattach.
      
      v2: Add Reported-by for syzbot
      
      Fixes: ab7ac4eb ("kcm: Kernel Connection Multiplexor module")
      Reported-by: syzbot+ea75c0ffcd353d32515f064aaebefc5279e6161e@syzkaller.appspotmail.com
      Signed-off-by: default avatarTom Herbert <tom@quantonium.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      406996f3
    • Florian Fainelli's avatar
      net: systemport: Rewrite __bcm_sysport_tx_reclaim() · 002f4557
      Florian Fainelli authored
      
      [ Upstream commit 484d802d ]
      
      There is no need for complex checking between the last consumed index
      and current consumed index, a simple subtraction will do.
      
      This also eliminates the possibility of a permanent transmit queue stall
      under the following conditions:
      
      - one CPU bursts ring->size worth of traffic (up to 256 buffers), to the
        point where we run out of free descriptors, so we stop the transmit
        queue at the end of bcm_sysport_xmit()
      
      - because of our locking, we have the transmit process disable
        interrupts which means we can be blocking the TX reclamation process
      
      - when TX reclamation finally runs, we will be computing the difference
        between ring->c_index (last consumed index by SW) and what the HW
        reports through its register
      
      - this register is masked with (ring->size - 1) = 0xff, which will lead
        to stripping the upper bits of the index (register is 16-bits wide)
      
      - we will be computing last_tx_cn as 0, which means there is no work to
        be done, and we never wake-up the transmit queue, leaving it
        permanently disabled
      
      A practical example is e.g: ring->c_index aka last_c_index = 12, we
      pushed 256 entries, HW consumer index = 268, we mask it with 0xff = 12,
      so last_tx_cn == 0, nothing happens.
      
      Fixes: 80105bef ("net: systemport: add Broadcom SYSTEMPORT Ethernet MAC driver")
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      002f4557
    • Julian Wiedmann's avatar
      s390/qeth: on channel error, reject further cmd requests · 4751804d
      Julian Wiedmann authored
      
      [ Upstream commit a6c3d939 ]
      
      When the IRQ handler determines that one of the cmd IO channels has
      failed and schedules recovery, block any further cmd requests from
      being submitted. The request would inevitably stall, and prevent the
      recovery from making progress until the request times out.
      
      This sort of error was observed after Live Guest Relocation, where
      the pending IO on the READ channel intentionally gets terminated to
      kick-start recovery. Simultaneously the guest executed SIOCETHTOOL,
      triggering qeth to issue a QUERY CARD INFO command. The command
      then stalled in the inoperabel WRITE channel.
      Signed-off-by: default avatarJulian Wiedmann <jwi@linux.vnet.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4751804d
    • Julian Wiedmann's avatar
      s390/qeth: lock read device while queueing next buffer · 3426c365
      Julian Wiedmann authored
      
      [ Upstream commit 17bf8c9b ]
      
      For calling ccw_device_start(), issue_next_read() needs to hold the
      device's ccwlock.
      This is satisfied for the IRQ handler path (where qeth_irq() gets called
      under the ccwlock), but we need explicit locking for the initial call by
      the MPC initialization.
      Signed-off-by: default avatarJulian Wiedmann <jwi@linux.vnet.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3426c365
    • Julian Wiedmann's avatar
      s390/qeth: when thread completes, wake up all waiters · 9ff2636b
      Julian Wiedmann authored
      
      [ Upstream commit 1063e432 ]
      
      qeth_wait_for_threads() is potentially called by multiple users, make
      sure to notify all of them after qeth_clear_thread_running_bit()
      adjusted the thread_running_mask. With no timeout, callers would
      otherwise stall.
      Signed-off-by: default avatarJulian Wiedmann <jwi@linux.vnet.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9ff2636b