1. 23 Jun, 2020 34 commits
  2. 22 Jun, 2020 4 commits
    • Tuomas Tynkkynen's avatar
      usbnet: smsc95xx: Fix use-after-free after removal · b835a71e
      Tuomas Tynkkynen authored
      Syzbot reports an use-after-free in workqueue context:
      
      BUG: KASAN: use-after-free in mutex_unlock+0x19/0x40 kernel/locking/mutex.c:737
       mutex_unlock+0x19/0x40 kernel/locking/mutex.c:737
       __smsc95xx_mdio_read drivers/net/usb/smsc95xx.c:217 [inline]
       smsc95xx_mdio_read+0x583/0x870 drivers/net/usb/smsc95xx.c:278
       check_carrier+0xd1/0x2e0 drivers/net/usb/smsc95xx.c:644
       process_one_work+0x777/0xf90 kernel/workqueue.c:2274
       worker_thread+0xa8f/0x1430 kernel/workqueue.c:2420
       kthread+0x2df/0x300 kernel/kthread.c:255
      
      It looks like that smsc95xx_unbind() is freeing the structures that are
      still in use by the concurrently running workqueue callback. Thus switch
      to using cancel_delayed_work_sync() to ensure the work callback really
      is no longer active.
      
      Reported-by: syzbot+29dc7d4ae19b703ff947@syzkaller.appspotmail.com
      Signed-off-by: default avatarTuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b835a71e
    • Ido Schimmel's avatar
      mlxsw: spectrum: Do not rely on machine endianness · f3fe412b
      Ido Schimmel authored
      The second commit cited below performed a cast of 'u32 buffsize' to
      '(u16 *)' when calling mlxsw_sp_port_headroom_8x_adjust():
      
      mlxsw_sp_port_headroom_8x_adjust(mlxsw_sp_port, (u16 *) &buffsize);
      
      Colin noted that this will behave differently on big endian
      architectures compared to little endian architectures.
      
      Fix this by following Colin's suggestion and have the function accept
      and return 'u32' instead of passing the current size by reference.
      
      Fixes: da382875 ("mlxsw: spectrum: Extend to support Spectrum-3 ASIC")
      Fixes: 60833d54 ("mlxsw: spectrum: Adjust headroom buffers for 8x ports")
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Reported-by: default avatarColin Ian King <colin.king@canonical.com>
      Suggested-by: default avatarColin Ian King <colin.king@canonical.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f3fe412b
    • Dejin Zheng's avatar
      net: phy: smsc: fix printing too many logs · 6d61f483
      Dejin Zheng authored
      Commit 7ae7ad2f ("net: phy: smsc: use phy_read_poll_timeout()
      to simplify the code") will print a lot of logs as follows when Ethernet
      cable is not connected:
      
      [    4.473105] SMSC LAN8710/LAN8720 2188000.ethernet-1:00: lan87xx_read_status failed: -110
      
      When wait 640 ms for check ENERGYON bit, the timeout should not be
      regarded as an actual error and an error message also should not be
      printed. due to a hardware bug in LAN87XX device, it leads to unstable
      detection of plugging in Ethernet cable when LAN87xx is in Energy Detect
      Power-Down mode. the workaround for it involves, when the link is down,
      and at each read_status() call:
      
      - disable EDPD mode, forcing the PHY out of low-power mode
      - waiting 640ms to see if we have any energy detected from the media
      - re-enable entry to EDPD mode
      
      This is presumably enough to allow the PHY to notice that a cable is
      connected, and resume normal operations to negotiate with the partner.
      The problem is that when no media is detected, the 640ms wait times
      out and this commit was modified to prints an error message. it is an
      inappropriate conversion by used phy_read_poll_timeout() to introduce
      this bug. so fix this issue by use read_poll_timeout() to replace
      phy_read_poll_timeout().
      
      Fixes: 7ae7ad2f ("net: phy: smsc: use phy_read_poll_timeout() to simplify the code")
      Reported-by: default avatarKevin Groeneveld <kgroeneveld@gmail.com>
      Signed-off-by: default avatarDejin Zheng <zhengdejin5@gmail.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6d61f483
    • Felix Fietkau's avatar
      MAINTAINERS: update email address for Felix Fietkau · b0c34bde
      Felix Fietkau authored
      The old address has been bouncing for a while now
      Signed-off-by: default avatarFelix Fietkau <nbd@nbd.name>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b0c34bde
  3. 21 Jun, 2020 2 commits
    • Rob Gill's avatar
      net: Add MODULE_DESCRIPTION entries to network modules · 67c20de3
      Rob Gill authored
      The user tool modinfo is used to get information on kernel modules, including a
      description where it is available.
      
      This patch adds a brief MODULE_DESCRIPTION to the following modules:
      
      9p
      drop_monitor
      esp4_offload
      esp6_offload
      fou
      fou6
      ila
      sch_fq
      sch_fq_codel
      sch_hhf
      Signed-off-by: default avatarRob Gill <rrobgill@protonmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      67c20de3
    • David Howells's avatar
      rxrpc: Fix notification call on completion of discarded calls · 0041cd5a
      David Howells authored
      When preallocated service calls are being discarded, they're passed to
      ->discard_new_call() to have the caller clean up any attached higher-layer
      preallocated pieces before being marked completed.  However, the act of
      marking them completed now invokes the call's notification function - which
      causes a problem because that function might assume that the previously
      freed pieces of memory are still there.
      
      Fix this by setting a dummy notification function on the socket after
      calling ->discard_new_call().
      
      This results in the following kasan message when the kafs module is
      removed.
      
      ==================================================================
      BUG: KASAN: use-after-free in afs_wake_up_async_call+0x6aa/0x770 fs/afs/rxrpc.c:707
      Write of size 1 at addr ffff8880946c39e4 by task kworker/u4:1/21
      
      CPU: 0 PID: 21 Comm: kworker/u4:1 Not tainted 5.8.0-rc1-syzkaller #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Workqueue: netns cleanup_net
      Call Trace:
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0x18f/0x20d lib/dump_stack.c:118
       print_address_description.constprop.0.cold+0xd3/0x413 mm/kasan/report.c:383
       __kasan_report mm/kasan/report.c:513 [inline]
       kasan_report.cold+0x1f/0x37 mm/kasan/report.c:530
       afs_wake_up_async_call+0x6aa/0x770 fs/afs/rxrpc.c:707
       rxrpc_notify_socket+0x1db/0x5d0 net/rxrpc/recvmsg.c:40
       __rxrpc_set_call_completion.part.0+0x172/0x410 net/rxrpc/recvmsg.c:76
       __rxrpc_call_completed net/rxrpc/recvmsg.c:112 [inline]
       rxrpc_call_completed+0xca/0xf0 net/rxrpc/recvmsg.c:111
       rxrpc_discard_prealloc+0x781/0xab0 net/rxrpc/call_accept.c:233
       rxrpc_listen+0x147/0x360 net/rxrpc/af_rxrpc.c:245
       afs_close_socket+0x95/0x320 fs/afs/rxrpc.c:110
       afs_net_exit+0x1bc/0x310 fs/afs/main.c:155
       ops_exit_list.isra.0+0xa8/0x150 net/core/net_namespace.c:186
       cleanup_net+0x511/0xa50 net/core/net_namespace.c:603
       process_one_work+0x965/0x1690 kernel/workqueue.c:2269
       worker_thread+0x96/0xe10 kernel/workqueue.c:2415
       kthread+0x3b5/0x4a0 kernel/kthread.c:291
       ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293
      
      Allocated by task 6820:
       save_stack+0x1b/0x40 mm/kasan/common.c:48
       set_track mm/kasan/common.c:56 [inline]
       __kasan_kmalloc mm/kasan/common.c:494 [inline]
       __kasan_kmalloc.constprop.0+0xbf/0xd0 mm/kasan/common.c:467
       kmem_cache_alloc_trace+0x153/0x7d0 mm/slab.c:3551
       kmalloc include/linux/slab.h:555 [inline]
       kzalloc include/linux/slab.h:669 [inline]
       afs_alloc_call+0x55/0x630 fs/afs/rxrpc.c:141
       afs_charge_preallocation+0xe9/0x2d0 fs/afs/rxrpc.c:757
       afs_open_socket+0x292/0x360 fs/afs/rxrpc.c:92
       afs_net_init+0xa6c/0xe30 fs/afs/main.c:125
       ops_init+0xaf/0x420 net/core/net_namespace.c:151
       setup_net+0x2de/0x860 net/core/net_namespace.c:341
       copy_net_ns+0x293/0x590 net/core/net_namespace.c:482
       create_new_namespaces+0x3fb/0xb30 kernel/nsproxy.c:110
       unshare_nsproxy_namespaces+0xbd/0x1f0 kernel/nsproxy.c:231
       ksys_unshare+0x43d/0x8e0 kernel/fork.c:2983
       __do_sys_unshare kernel/fork.c:3051 [inline]
       __se_sys_unshare kernel/fork.c:3049 [inline]
       __x64_sys_unshare+0x2d/0x40 kernel/fork.c:3049
       do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:359
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      Freed by task 21:
       save_stack+0x1b/0x40 mm/kasan/common.c:48
       set_track mm/kasan/common.c:56 [inline]
       kasan_set_free_info mm/kasan/common.c:316 [inline]
       __kasan_slab_free+0xf7/0x140 mm/kasan/common.c:455
       __cache_free mm/slab.c:3426 [inline]
       kfree+0x109/0x2b0 mm/slab.c:3757
       afs_put_call+0x585/0xa40 fs/afs/rxrpc.c:190
       rxrpc_discard_prealloc+0x764/0xab0 net/rxrpc/call_accept.c:230
       rxrpc_listen+0x147/0x360 net/rxrpc/af_rxrpc.c:245
       afs_close_socket+0x95/0x320 fs/afs/rxrpc.c:110
       afs_net_exit+0x1bc/0x310 fs/afs/main.c:155
       ops_exit_list.isra.0+0xa8/0x150 net/core/net_namespace.c:186
       cleanup_net+0x511/0xa50 net/core/net_namespace.c:603
       process_one_work+0x965/0x1690 kernel/workqueue.c:2269
       worker_thread+0x96/0xe10 kernel/workqueue.c:2415
       kthread+0x3b5/0x4a0 kernel/kthread.c:291
       ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293
      
      The buggy address belongs to the object at ffff8880946c3800
       which belongs to the cache kmalloc-1k of size 1024
      The buggy address is located 484 bytes inside of
       1024-byte region [ffff8880946c3800, ffff8880946c3c00)
      The buggy address belongs to the page:
      page:ffffea000251b0c0 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0
      flags: 0xfffe0000000200(slab)
      raw: 00fffe0000000200 ffffea0002546508 ffffea00024fa248 ffff8880aa000c40
      raw: 0000000000000000 ffff8880946c3000 0000000100000002 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
       ffff8880946c3880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff8880946c3900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      >ffff8880946c3980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                                             ^
       ffff8880946c3a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff8880946c3a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      ==================================================================
      
      Reported-by: syzbot+d3eccef36ddbd02713e9@syzkaller.appspotmail.com
      Fixes: 5ac0d622 ("rxrpc: Fix missing notification")
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0041cd5a