1. 14 Dec, 2018 2 commits
  2. 13 Dec, 2018 21 commits
  3. 12 Dec, 2018 8 commits
  4. 11 Dec, 2018 6 commits
    • David S. Miller's avatar
      Merge branch 'ieee802154-for-davem-2018-12-11' of... · 2f1a9f66
      David S. Miller authored
      Merge branch 'ieee802154-for-davem-2018-12-11' of git://git.kernel.org/pub/scm/linux/kernel/git/sschmidt/wpan
      
      Stefan Schmidt says:
      
      ====================
      pull-request: ieee802154 for net 2018-12-11
      
      An update from ieee802154 for your *net* tree.
      
      Just two more fixes for ieee802154 dribver before the final 4.20 release.
      Alexander Aring fixes a problem in the nested parsing code of the
      hwsim driver interface.
      A fix for a potential overflow in the ca8210 driver by Yue Habing.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2f1a9f66
    • YueHaibing's avatar
      ieee802154: ca8210: fix possible u8 overflow in ca8210_rx_done · 8e41cae6
      YueHaibing authored
      gcc warning this:
      
      drivers/net/ieee802154/ca8210.c:730:10: warning:
       comparison is always false due to limited range of data type [-Wtype-limits]
      
      'len' is u8 type, we get it from buf[1] adding 2, which can overflow.
      This patch change the type of 'len' to unsigned int to avoid this,also fix
      the gcc warning.
      
      Fixes: ded845a7 ("ieee802154: Add CA8210 IEEE 802.15.4 device driver")
      Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
      Signed-off-by: default avatarStefan Schmidt <stefan@datenfreihafen.org>
      8e41cae6
    • Pieter Jansen van Vuuren's avatar
      nfp: flower: ensure TCP flags can be placed in IPv6 frame · 290974d4
      Pieter Jansen van Vuuren authored
      Previously we did not ensure tcp flags have a place to be stored
      when using IPv6. We correct this by including IPv6 key layer when
      we match tcp flags and the IPv6 key layer has not been included
      already.
      
      Fixes: 07e1671c ("nfp: flower: refactor shared ip header in match offload")
      Signed-off-by: default avatarPieter Jansen van Vuuren <pieter.jansenvanvuuren@netronome.com>
      Reviewed-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      290974d4
    • David S. Miller's avatar
      Merge branch 'ibmvnic-Fix-reset-work-item-locking-bugs' · 6cbe7210
      David S. Miller authored
      Thomas Falcon says:
      
      ====================
      net/ibmvnic: Fix reset work item locking bugs
      
      This patch set fixes issues with scheduling reset work items in
      a tasklet context. Since ibmvnic_reset can called in an interrupt,
      it should not use a mutex or allocate memory non-atomically.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6cbe7210
    • Thomas Falcon's avatar
      ibmvnic: Fix non-atomic memory allocation in IRQ context · 1d1bbc37
      Thomas Falcon authored
      ibmvnic_reset allocated new reset work item objects in a non-atomic
      context. This can be called from a tasklet, generating the output below.
      Allocate work items with the GFP_ATOMIC flag instead.
      
      BUG: sleeping function called from invalid context at mm/slab.h:421
      in_atomic(): 1, irqs_disabled(): 1, pid: 93, name: kworker/0:2
      INFO: lockdep is turned off.
      irq event stamp: 66049
      hardirqs last  enabled at (66048): [<c000000000122468>] tasklet_action_common.isra.12+0x78/0x1c0
      hardirqs last disabled at (66049): [<c000000000befce8>] _raw_spin_lock_irqsave+0x48/0xf0
      softirqs last  enabled at (66044): [<c000000000a8ac78>] dev_deactivate_queue.constprop.28+0xc8/0x160
      softirqs last disabled at (66045): [<c0000000000306e0>] call_do_softirq+0x14/0x24
      CPU: 0 PID: 93 Comm: kworker/0:2 Kdump: loaded Not tainted 4.20.0-rc6-00001-g1b50a8f03706 #7
      Workqueue: events linkwatch_event
      Call Trace:
      [c0000003fffe7ae0] [c000000000bc83e4] dump_stack+0xe8/0x164 (unreliable)
      [c0000003fffe7b30] [c00000000015ba0c] ___might_sleep+0x2dc/0x320
      [c0000003fffe7bb0] [c000000000391514] kmem_cache_alloc_trace+0x3e4/0x440
      [c0000003fffe7c30] [d000000005b2309c] ibmvnic_reset+0x16c/0x360 [ibmvnic]
      [c0000003fffe7cc0] [d000000005b29834] ibmvnic_tasklet+0x1054/0x2010 [ibmvnic]
      [c0000003fffe7e00] [c0000000001224c8] tasklet_action_common.isra.12+0xd8/0x1c0
      [c0000003fffe7e60] [c000000000bf1238] __do_softirq+0x1a8/0x64c
      [c0000003fffe7f90] [c0000000000306e0] call_do_softirq+0x14/0x24
      [c0000003f3967980] [c00000000001ba50] do_softirq_own_stack+0x60/0xb0
      [c0000003f39679c0] [c0000000001218a8] do_softirq+0xa8/0x100
      [c0000003f39679f0] [c000000000121a74] __local_bh_enable_ip+0x174/0x180
      [c0000003f3967a60] [c000000000bf003c] _raw_spin_unlock_bh+0x5c/0x80
      [c0000003f3967a90] [c000000000a8ac78] dev_deactivate_queue.constprop.28+0xc8/0x160
      [c0000003f3967ad0] [c000000000a8c8b0] dev_deactivate_many+0xd0/0x520
      [c0000003f3967b70] [c000000000a8cd40] dev_deactivate+0x40/0x60
      [c0000003f3967ba0] [c000000000a5e0c4] linkwatch_do_dev+0x74/0xd0
      [c0000003f3967bd0] [c000000000a5e694] __linkwatch_run_queue+0x1a4/0x1f0
      [c0000003f3967c30] [c000000000a5e728] linkwatch_event+0x48/0x60
      [c0000003f3967c50] [c0000000001444e8] process_one_work+0x238/0x710
      [c0000003f3967d20] [c000000000144a48] worker_thread+0x88/0x4e0
      [c0000003f3967db0] [c00000000014e3a8] kthread+0x178/0x1c0
      [c0000003f3967e20] [c00000000000bfd0] ret_from_kernel_thread+0x5c/0x6c
      Signed-off-by: default avatarThomas Falcon <tlfalcon@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1d1bbc37
    • Thomas Falcon's avatar
      ibmvnic: Convert reset work item mutex to spin lock · 6c5c7489
      Thomas Falcon authored
      ibmvnic_reset can create and schedule a reset work item from
      an IRQ context, so do not use a mutex, which can sleep. Convert
      the reset work item mutex to a spin lock. Locking debugger generated
      the trace output below.
      
      BUG: sleeping function called from invalid context at kernel/locking/mutex.c:908
      in_atomic(): 1, irqs_disabled(): 1, pid: 120, name: kworker/8:1
      4 locks held by kworker/8:1/120:
       #0: 0000000017c05720 ((wq_completion)"events"){+.+.}, at: process_one_work+0x188/0x710
       #1: 00000000ace90706 ((linkwatch_work).work){+.+.}, at: process_one_work+0x188/0x710
       #2: 000000007632871f (rtnl_mutex){+.+.}, at: rtnl_lock+0x30/0x50
       #3: 00000000fc36813a (&(&crq->lock)->rlock){..-.}, at: ibmvnic_tasklet+0x88/0x2010 [ibmvnic]
      irq event stamp: 26293
      hardirqs last  enabled at (26292): [<c000000000122468>] tasklet_action_common.isra.12+0x78/0x1c0
      hardirqs last disabled at (26293): [<c000000000befce8>] _raw_spin_lock_irqsave+0x48/0xf0
      softirqs last  enabled at (26288): [<c000000000a8ac78>] dev_deactivate_queue.constprop.28+0xc8/0x160
      softirqs last disabled at (26289): [<c0000000000306e0>] call_do_softirq+0x14/0x24
      CPU: 8 PID: 120 Comm: kworker/8:1 Kdump: loaded Not tainted 4.20.0-rc6 #6
      Workqueue: events linkwatch_event
      Call Trace:
      [c0000003fffa7a50] [c000000000bc83e4] dump_stack+0xe8/0x164 (unreliable)
      [c0000003fffa7aa0] [c00000000015ba0c] ___might_sleep+0x2dc/0x320
      [c0000003fffa7b20] [c000000000be960c] __mutex_lock+0x8c/0xb40
      [c0000003fffa7c30] [d000000006202ac8] ibmvnic_reset+0x78/0x330 [ibmvnic]
      [c0000003fffa7cc0] [d0000000062097f4] ibmvnic_tasklet+0x1054/0x2010 [ibmvnic]
      [c0000003fffa7e00] [c0000000001224c8] tasklet_action_common.isra.12+0xd8/0x1c0
      [c0000003fffa7e60] [c000000000bf1238] __do_softirq+0x1a8/0x64c
      [c0000003fffa7f90] [c0000000000306e0] call_do_softirq+0x14/0x24
      [c0000003f3f87980] [c00000000001ba50] do_softirq_own_stack+0x60/0xb0
      [c0000003f3f879c0] [c0000000001218a8] do_softirq+0xa8/0x100
      [c0000003f3f879f0] [c000000000121a74] __local_bh_enable_ip+0x174/0x180
      [c0000003f3f87a60] [c000000000bf003c] _raw_spin_unlock_bh+0x5c/0x80
      [c0000003f3f87a90] [c000000000a8ac78] dev_deactivate_queue.constprop.28+0xc8/0x160
      [c0000003f3f87ad0] [c000000000a8c8b0] dev_deactivate_many+0xd0/0x520
      [c0000003f3f87b70] [c000000000a8cd40] dev_deactivate+0x40/0x60
      [c0000003f3f87ba0] [c000000000a5e0c4] linkwatch_do_dev+0x74/0xd0
      [c0000003f3f87bd0] [c000000000a5e694] __linkwatch_run_queue+0x1a4/0x1f0
      [c0000003f3f87c30] [c000000000a5e728] linkwatch_event+0x48/0x60
      [c0000003f3f87c50] [c0000000001444e8] process_one_work+0x238/0x710
      [c0000003f3f87d20] [c000000000144a48] worker_thread+0x88/0x4e0
      [c0000003f3f87db0] [c00000000014e3a8] kthread+0x178/0x1c0
      [c0000003f3f87e20] [c00000000000bfd0] ret_from_kernel_thread+0x5c/0x6c
      Signed-off-by: default avatarThomas Falcon <tlfalcon@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6c5c7489
  5. 10 Dec, 2018 2 commits
    • Gustavo A. R. Silva's avatar
      ipv4: Fix potential Spectre v1 vulnerability · 5648451e
      Gustavo A. R. Silva authored
      vr.vifi is indirectly controlled by user-space, hence leading to
      a potential exploitation of the Spectre variant 1 vulnerability.
      
      This issue was detected with the help of Smatch:
      
      net/ipv4/ipmr.c:1616 ipmr_ioctl() warn: potential spectre issue 'mrt->vif_table' [r] (local cap)
      net/ipv4/ipmr.c:1690 ipmr_compat_ioctl() warn: potential spectre issue 'mrt->vif_table' [r] (local cap)
      
      Fix this by sanitizing vr.vifi before using it to index mrt->vif_table'
      
      Notice that given that speculation windows are large, the policy is
      to kill the speculation on the first load and not worry if it can be
      completed with a dependent load/store [1].
      
      [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5648451e
    • Xin Long's avatar
      sctp: initialize sin6_flowinfo for ipv6 addrs in sctp_inet6addr_event · 4a2eb0c3
      Xin Long authored
      syzbot reported a kernel-infoleak, which is caused by an uninitialized
      field(sin6_flowinfo) of addr->a.v6 in sctp_inet6addr_event().
      The call trace is as below:
      
        BUG: KMSAN: kernel-infoleak in _copy_to_user+0x19a/0x230 lib/usercopy.c:33
        CPU: 1 PID: 8164 Comm: syz-executor2 Not tainted 4.20.0-rc3+ #95
        Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
        Google 01/01/2011
        Call Trace:
          __dump_stack lib/dump_stack.c:77 [inline]
          dump_stack+0x32d/0x480 lib/dump_stack.c:113
          kmsan_report+0x12c/0x290 mm/kmsan/kmsan.c:683
          kmsan_internal_check_memory+0x32a/0xa50 mm/kmsan/kmsan.c:743
          kmsan_copy_to_user+0x78/0xd0 mm/kmsan/kmsan_hooks.c:634
          _copy_to_user+0x19a/0x230 lib/usercopy.c:33
          copy_to_user include/linux/uaccess.h:183 [inline]
          sctp_getsockopt_local_addrs net/sctp/socket.c:5998 [inline]
          sctp_getsockopt+0x15248/0x186f0 net/sctp/socket.c:7477
          sock_common_getsockopt+0x13f/0x180 net/core/sock.c:2937
          __sys_getsockopt+0x489/0x550 net/socket.c:1939
          __do_sys_getsockopt net/socket.c:1950 [inline]
          __se_sys_getsockopt+0xe1/0x100 net/socket.c:1947
          __x64_sys_getsockopt+0x62/0x80 net/socket.c:1947
          do_syscall_64+0xcf/0x110 arch/x86/entry/common.c:291
          entry_SYSCALL_64_after_hwframe+0x63/0xe7
      
      sin6_flowinfo is not really used by SCTP, so it will be fixed by simply
      setting it to 0.
      
      The issue exists since very beginning.
      Thanks Alexander for the reproducer provided.
      
      Reported-by: syzbot+ad5d327e6936a2e284be@syzkaller.appspotmail.com
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Acked-by: default avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4a2eb0c3
  6. 09 Dec, 2018 1 commit