1. 25 Jun, 2019 2 commits
    • Brian Norris's avatar
      mwifiex: drop 'set_consistent_dma_mask' log message · f7369179
      Brian Norris authored
      This message is pointless.
      
      While we're at it, include the error code in the error message, which is
      not pointless.
      Signed-off-by: default avatarBrian Norris <briannorris@chromium.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      f7369179
    • Alan Stern's avatar
      p54usb: Fix race between disconnect and firmware loading · 6e41e225
      Alan Stern authored
      The syzbot fuzzer found a bug in the p54 USB wireless driver.  The
      issue involves a race between disconnect and the firmware-loader
      callback routine, and it has several aspects.
      
      One big problem is that when the firmware can't be loaded, the
      callback routine tries to unbind the driver from the USB _device_ (by
      calling device_release_driver) instead of from the USB _interface_ to
      which it is actually bound (by calling usb_driver_release_interface).
      
      The race involves access to the private data structure.  The driver's
      disconnect handler waits for a completion that is signalled by the
      firmware-loader callback routine.  As soon as the completion is
      signalled, you have to assume that the private data structure may have
      been deallocated by the disconnect handler -- even if the firmware was
      loaded without errors.  However, the callback routine does access the
      private data several times after that point.
      
      Another problem is that, in order to ensure that the USB device
      structure hasn't been freed when the callback routine runs, the driver
      takes a reference to it.  This isn't good enough any more, because now
      that the callback routine calls usb_driver_release_interface, it has
      to ensure that the interface structure hasn't been freed.
      
      Finally, the driver takes an unnecessary reference to the USB device
      structure in the probe function and drops the reference in the
      disconnect handler.  This extra reference doesn't accomplish anything,
      because the USB core already guarantees that a device structure won't
      be deallocated while a driver is still bound to any of its interfaces.
      
      To fix these problems, this patch makes the following changes:
      
      	Call usb_driver_release_interface() rather than
      	device_release_driver().
      
      	Don't signal the completion until after the important
      	information has been copied out of the private data structure,
      	and don't refer to the private data at all thereafter.
      
      	Lock udev (the interface's parent) before unbinding the driver
      	instead of locking udev->parent.
      
      	During the firmware loading process, take a reference to the
      	USB interface instead of the USB device.
      
      	Don't take an unnecessary reference to the device during probe
      	(and then don't drop it during disconnect).
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Reported-and-tested-by: syzbot+200d4bb11b23d929335f@syzkaller.appspotmail.com
      CC: <stable@vger.kernel.org>
      Acked-by: default avatarChristian Lamparter <chunkeey@gmail.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      6e41e225
  2. 28 May, 2019 26 commits
  3. 27 May, 2019 5 commits
    • Kalle Valo's avatar
      Merge ath-next from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git · 889ca180
      Kalle Valo authored
      ath.git patches for 5.3. Major changes:
      
      ath10k
      
      * enable SDIO support, first one being QCA6174 hw3.2
      889ca180
    • YueHaibing's avatar
      cxgb4: Make t4_get_tp_e2c_map static · f4aa8012
      YueHaibing authored
      Fix sparse warning:
      
      drivers/net/ethernet/chelsio/cxgb4/t4_hw.c:6216:14:
       warning: symbol 't4_get_tp_e2c_map' was not declared. Should it be static?
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f4aa8012
    • David Ahern's avatar
      selftest: Fixes for icmp_redirect test · 99513cfa
      David Ahern authored
      I was really surprised that the IPv6 mtu exception followed by redirect
      test was passing as nothing about the code suggests it should. The problem
      is actually with the logic in the test script.
      
      Fix the test cases as follows:
      1. add debug function to dump the initial and redirect gateway addresses
         for ipv6. This is shown only in verbose mode. It helps verify the
         output of 'route get'.
      
      2. fix the check_exception logic for the reset case to make sure that
         for IPv4 neither mtu nor redirect appears in the 'route get' output.
         For IPv6, make sure mtu is not present and the gateway is the initial
         R1 lladdr.
      
      3. fix the reset logic by using a function to delete the routes added by
         initial_route_*. This format works better for the nexthop version of
         the tests.
      
      While improving the test cases, go ahead and ensure that forwarding is
      disabled since IPv6 redirect requires it.
      
      Also, runs with kernel debugging enabled sometimes show a failure with
      one of the ipv4 tests, so spread the pings over longer time interval.
      
      The end result is that 2 tests now show failures:
      
      TEST: IPv6: mtu exception plus redirect                    [FAIL]
      
      and the VRF version.
      
      This is a bug in the IPv6 logic that will need to be fixed
      separately. Redirect followed by MTU works because __ip6_rt_update_pmtu
      hits the 'if (!rt6_cache_allowed_for_pmtu(rt6))' path and updates the
      mtu on the exception rt6_info.
      
      MTU followed by redirect does not have this logic. rt6_do_redirect
      creates a new exception and then rt6_insert_exception removes the old
      one which has the MTU exception.
      
      Fixes: ec810535 ("selftests: Add redirect tests")
      Signed-off-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      99513cfa
    • Colin Ian King's avatar
      ipv4: remove redundant assignment to n · df801522
      Colin Ian King authored
      The pointer n is being assigned a value however this value is
      never read in the code block and the end of the code block
      continues to the next loop iteration. Clean up the code by
      removing the redundant assignment.
      
      Fixes: 1bff1a0c ("ipv4: Add function to send route updates")
      Addresses-Coverity: ("Unused value")
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      df801522
    • Heiner Kallweit's avatar
      net: phy: bcm87xx: improve bcm87xx_config_init and feature detection · 476cc6c9
      Heiner Kallweit authored
      PHY drivers don't have to and shouldn't fiddle with phylib internals.
      Most of the code in bcm87xx_config_init() can be removed because
      phylib takes care.
      
      In addition I replaced usage of PHY_10GBIT_FEC_FEATURES with an
      implementation of the get_features callback. PHY_10GBIT_FEC_FEATURES
      is used by this driver only and it's questionable whether there
      will be any other PHY supporting this mode only. Having said that
      in one of the next kernel versions we may decide to remove it.
      Signed-off-by: default avatarHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      476cc6c9
  4. 26 May, 2019 7 commits
    • David S. Miller's avatar
      Merge branch 'inet-frags-avoid-possible-races-at-netns-dismantle' · 8fb91c35
      David S. Miller authored
      Eric Dumazet says:
      
      ====================
      inet: frags: avoid possible races at netns dismantle
      
      This patch series fixes a race happening on netns dismantle with
      frag queues. While rhashtable_free_and_destroy() is running,
      concurrent timers might run inet_frag_kill() and attempt
      rhashtable_remove_fast() calls. This is not allowed by
      rhashtable logic.
      
      Since I do not want to add expensive synchronize_rcu() calls
      in the netns dismantle path, I had to no longer inline
      netns_frags structures, but dynamically allocate them.
      
      The ten first patches make this preparation, so that
      the last patch clearly shows the fix.
      
      As this patch series is not exactly trivial, I chose to
      target 5.3. We will backport it once soaked a bit.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8fb91c35
    • Eric Dumazet's avatar
      inet: frags: rework rhashtable dismantle · 3c8fc878
      Eric Dumazet authored
      syszbot found an interesting use-after-free [1] happening
      while IPv4 fragment rhashtable was destroyed at netns dismantle.
      
      While no insertions can possibly happen at the time a dismantling
      netns is destroying this rhashtable, timers can still fire and
      attempt to remove elements from this rhashtable.
      
      This is forbidden, since rhashtable_free_and_destroy() has
      no synchronization against concurrent inserts and deletes.
      
      Add a new fqdir->dead flag so that timers do not attempt
      a rhashtable_remove_fast() operation.
      
      We also have to respect an RCU grace period before starting
      the rhashtable_free_and_destroy() from process context,
      thus we use rcu_work infrastructure.
      
      This is a refinement of a prior rough attempt to fix this bug :
      https://marc.info/?l=linux-netdev&m=153845936820900&w=2
      
      Since the rhashtable cleanup is now deferred to a work queue,
      netns dismantles should be slightly faster.
      
      [1]
      BUG: KASAN: use-after-free in __read_once_size include/linux/compiler.h:194 [inline]
      BUG: KASAN: use-after-free in rhashtable_last_table+0x162/0x180 lib/rhashtable.c:212
      Read of size 8 at addr ffff8880a6497b70 by task kworker/0:0/5
      
      CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.2.0-rc1+ #2
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Workqueue: events rht_deferred_worker
      Call Trace:
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0x172/0x1f0 lib/dump_stack.c:113
       print_address_description.cold+0x7c/0x20d mm/kasan/report.c:188
       __kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
       kasan_report+0x12/0x20 mm/kasan/common.c:614
       __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:132
       __read_once_size include/linux/compiler.h:194 [inline]
       rhashtable_last_table+0x162/0x180 lib/rhashtable.c:212
       rht_deferred_worker+0x111/0x2030 lib/rhashtable.c:411
       process_one_work+0x989/0x1790 kernel/workqueue.c:2269
       worker_thread+0x98/0xe40 kernel/workqueue.c:2415
       kthread+0x354/0x420 kernel/kthread.c:255
       ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
      
      Allocated by task 32687:
       save_stack+0x23/0x90 mm/kasan/common.c:71
       set_track mm/kasan/common.c:79 [inline]
       __kasan_kmalloc mm/kasan/common.c:489 [inline]
       __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:462
       kasan_kmalloc+0x9/0x10 mm/kasan/common.c:503
       __do_kmalloc_node mm/slab.c:3620 [inline]
       __kmalloc_node+0x4e/0x70 mm/slab.c:3627
       kmalloc_node include/linux/slab.h:590 [inline]
       kvmalloc_node+0x68/0x100 mm/util.c:431
       kvmalloc include/linux/mm.h:637 [inline]
       kvzalloc include/linux/mm.h:645 [inline]
       bucket_table_alloc+0x90/0x480 lib/rhashtable.c:178
       rhashtable_init+0x3f4/0x7b0 lib/rhashtable.c:1057
       inet_frags_init_net include/net/inet_frag.h:109 [inline]
       ipv4_frags_init_net+0x182/0x410 net/ipv4/ip_fragment.c:683
       ops_init+0xb3/0x410 net/core/net_namespace.c:130
       setup_net+0x2d3/0x740 net/core/net_namespace.c:316
       copy_net_ns+0x1df/0x340 net/core/net_namespace.c:439
       create_new_namespaces+0x400/0x7b0 kernel/nsproxy.c:107
       unshare_nsproxy_namespaces+0xc2/0x200 kernel/nsproxy.c:206
       ksys_unshare+0x440/0x980 kernel/fork.c:2692
       __do_sys_unshare kernel/fork.c:2760 [inline]
       __se_sys_unshare kernel/fork.c:2758 [inline]
       __x64_sys_unshare+0x31/0x40 kernel/fork.c:2758
       do_syscall_64+0xfd/0x680 arch/x86/entry/common.c:301
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Freed by task 7:
       save_stack+0x23/0x90 mm/kasan/common.c:71
       set_track mm/kasan/common.c:79 [inline]
       __kasan_slab_free+0x102/0x150 mm/kasan/common.c:451
       kasan_slab_free+0xe/0x10 mm/kasan/common.c:459
       __cache_free mm/slab.c:3432 [inline]
       kfree+0xcf/0x220 mm/slab.c:3755
       kvfree+0x61/0x70 mm/util.c:460
       bucket_table_free+0x69/0x150 lib/rhashtable.c:108
       rhashtable_free_and_destroy+0x165/0x8b0 lib/rhashtable.c:1155
       inet_frags_exit_net+0x3d/0x50 net/ipv4/inet_fragment.c:152
       ipv4_frags_exit_net+0x73/0x90 net/ipv4/ip_fragment.c:695
       ops_exit_list.isra.0+0xaa/0x150 net/core/net_namespace.c:154
       cleanup_net+0x3fb/0x960 net/core/net_namespace.c:553
       process_one_work+0x989/0x1790 kernel/workqueue.c:2269
       worker_thread+0x98/0xe40 kernel/workqueue.c:2415
       kthread+0x354/0x420 kernel/kthread.c:255
       ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
      
      The buggy address belongs to the object at ffff8880a6497b40
       which belongs to the cache kmalloc-1k of size 1024
      The buggy address is located 48 bytes inside of
       1024-byte region [ffff8880a6497b40, ffff8880a6497f40)
      The buggy address belongs to the page:
      page:ffffea0002992580 refcount:1 mapcount:0 mapping:ffff8880aa400ac0 index:0xffff8880a64964c0 compound_mapcount: 0
      flags: 0x1fffc0000010200(slab|head)
      raw: 01fffc0000010200 ffffea0002916e88 ffffea000218fe08 ffff8880aa400ac0
      raw: ffff8880a64964c0 ffff8880a6496040 0000000100000005 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
       ffff8880a6497a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff8880a6497a80: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
      >ffff8880a6497b00: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
                                                                   ^
       ffff8880a6497b80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff8880a6497c00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      
      Fixes: 648700f7 ("inet: frags: use rhashtables for reassembly units")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3c8fc878
    • Eric Dumazet's avatar
      net: dynamically allocate fqdir structures · 4907abc6
      Eric Dumazet authored
      Following patch will add rcu grace period before fqdir
      rhashtable destruction, so we need to dynamically allocate
      fqdir structures to not force expensive synchronize_rcu() calls
      in netns dismantle path.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4907abc6
    • Eric Dumazet's avatar
      net: add a net pointer to struct fqdir · a39aca67
      Eric Dumazet authored
      fqdir will soon be dynamically allocated.
      
      We need to reach the struct net pointer from fqdir,
      so add it, and replace the various container_of() constructs
      by direct access to the new field.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a39aca67
    • Eric Dumazet's avatar
      net: rename inet_frags_init_net() to fdir_init() · 9cce45f2
      Eric Dumazet authored
      And pass an extra parameter, since we will soon
      dynamically allocate fqdir structures.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9cce45f2
    • Eric Dumazet's avatar
      ieee820154: 6lowpan: no longer reference init_net in lowpan_frags_ns_ctl_table · d2dfd435
      Eric Dumazet authored
      (struct net *)->ieee802154_lowpan.fqdir will soon be a pointer, so make
      sure lowpan_frags_ns_ctl_table[] does not reference init_net.
      
      lowpan_frags_ns_sysctl_register() can perform the needed initialization
      for all netns.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d2dfd435
    • Eric Dumazet's avatar
      netfilter: ipv6: nf_defrag: no longer reference init_net in nf_ct_frag6_sysctl_table · 3bb13dd4
      Eric Dumazet authored
      (struct net *)->nf_frag.fqdir will soon be a pointer, so make
      sure nf_ct_frag6_sysctl_table[] does not reference init_net.
      
      nf_ct_frag6_sysctl_register() can perform the needed initialization
      for all netns.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3bb13dd4