1. 24 6月, 2020 28 次提交
  2. 23 6月, 2020 8 次提交
    • A
      GUE: Fix a typo · 26ac10be
      Aiden Leong 提交于
      Fix a typo in gue.h
      Signed-off-by: NAiden Leong <aiden.leong@aibsd.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      26ac10be
    • G
      mptcp: drop sndr_key in mptcp_syn_options · b562f58b
      Geliang Tang 提交于
      In RFC 8684, we don't need to send sndr_key in SYN package anymore, so drop
      it.
      
      Fixes: cc7972ea ("mptcp: parse and emit MP_CAPABLE option according to v1 spec")
      Signed-off-by: NGeliang Tang <geliangtang@gmail.com>
      Reviewed-by: NMatthieu Baerts <matthieu.baerts@tessares.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b562f58b
    • G
      ethtool: Fix check in ethtool_rx_flow_rule_create · 21a739c6
      Gaurav Singh 提交于
      Fix check in ethtool_rx_flow_rule_create
      
      Fixes: eca4205f ("ethtool: add ethtool_rx_flow_spec to flow_rule structure translator")
      Signed-off-by: NGaurav Singh <gaurav1086@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      21a739c6
    • T
      hsr: avoid to create proc file after unregister · de0083c7
      Taehee Yoo 提交于
      When an interface is being deleted, "/proc/net/dev_snmp6/<interface name>"
      is deleted.
      The function for this is addrconf_ifdown() in the addrconf_notify() and
      it is called by notification, which is NETDEV_UNREGISTER.
      But, if NETDEV_CHANGEMTU is triggered after NETDEV_UNREGISTER,
      this proc file will be created again.
      This recreated proc file will be deleted by netdev_wati_allrefs().
      Before netdev_wait_allrefs() is called, creating a new HSR interface
      routine can be executed and It tries to create a proc file but it will
      find an un-deleted proc file.
      At this point, it warns about it.
      
      To avoid this situation, it can use ->dellink() instead of
      ->ndo_uninit() to release resources because ->dellink() is called
      before NETDEV_UNREGISTER.
      So, a proc file will not be recreated.
      
      Test commands
          ip link add dummy0 type dummy
          ip link add dummy1 type dummy
          ip link set dummy0 mtu 1300
      
          #SHELL1
          while :
          do
              ip link add hsr0 type hsr slave1 dummy0 slave2 dummy1
          done
      
          #SHELL2
          while :
          do
              ip link del hsr0
          done
      
      Splat looks like:
      [ 9888.980852][ T2752] proc_dir_entry 'dev_snmp6/hsr0' already registered
      [ 9888.981797][    C2] WARNING: CPU: 2 PID: 2752 at fs/proc/generic.c:372 proc_register+0x2d5/0x430
      [ 9888.981798][    C2] Modules linked in: hsr dummy veth openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6x
      [ 9888.981814][    C2] CPU: 2 PID: 2752 Comm: ip Tainted: G        W         5.8.0-rc1+ #616
      [ 9888.981815][    C2] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
      [ 9888.981816][    C2] RIP: 0010:proc_register+0x2d5/0x430
      [ 9888.981818][    C2] Code: fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 65 01 00 00 49 8b b5 e0 00 00 00 48 89 ea 40
      [ 9888.981819][    C2] RSP: 0018:ffff8880628dedf0 EFLAGS: 00010286
      [ 9888.981821][    C2] RAX: dffffc0000000008 RBX: ffff888028c69170 RCX: ffffffffaae09a62
      [ 9888.981822][    C2] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffff88806c9f75ac
      [ 9888.981823][    C2] RBP: ffff888028c693f4 R08: ffffed100d9401bd R09: ffffed100d9401bd
      [ 9888.981824][    C2] R10: ffffffffaddf406f R11: 0000000000000001 R12: ffff888028c69308
      [ 9888.981825][    C2] R13: ffff8880663584c8 R14: dffffc0000000000 R15: ffffed100518d27e
      [ 9888.981827][    C2] FS:  00007f3876b3b0c0(0000) GS:ffff88806c800000(0000) knlGS:0000000000000000
      [ 9888.981828][    C2] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [ 9888.981829][    C2] CR2: 00007f387601a8c0 CR3: 000000004101a002 CR4: 00000000000606e0
      [ 9888.981830][    C2] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [ 9888.981831][    C2] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [ 9888.981832][    C2] Call Trace:
      [ 9888.981833][    C2]  ? snmp6_seq_show+0x180/0x180
      [ 9888.981834][    C2]  proc_create_single_data+0x7c/0xa0
      [ 9888.981835][    C2]  snmp6_register_dev+0xb0/0x130
      [ 9888.981836][    C2]  ipv6_add_dev+0x4b7/0xf60
      [ 9888.981837][    C2]  addrconf_notify+0x684/0x1ca0
      [ 9888.981838][    C2]  ? __mutex_unlock_slowpath+0xd0/0x670
      [ 9888.981839][    C2]  ? kasan_unpoison_shadow+0x30/0x40
      [ 9888.981840][    C2]  ? wait_for_completion+0x250/0x250
      [ 9888.981841][    C2]  ? inet6_ifinfo_notify+0x100/0x100
      [ 9888.981842][    C2]  ? dropmon_net_event+0x227/0x410
      [ 9888.981843][    C2]  ? notifier_call_chain+0x90/0x160
      [ 9888.981844][    C2]  ? inet6_ifinfo_notify+0x100/0x100
      [ 9888.981845][    C2]  notifier_call_chain+0x90/0x160
      [ 9888.981846][    C2]  register_netdevice+0xbe5/0x1070
      [ ... ]
      
      Reported-by: syzbot+1d51c8b74efa4c44adeb@syzkaller.appspotmail.com
      Fixes: e0a4b997 ("hsr: use upper/lower device infrastructure")
      Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      de0083c7
    • T
      usbnet: smsc95xx: Fix use-after-free after removal · b835a71e
      Tuomas Tynkkynen 提交于
      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: NTuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b835a71e
    • I
      mlxsw: spectrum: Do not rely on machine endianness · f3fe412b
      Ido Schimmel 提交于
      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: NIdo Schimmel <idosch@mellanox.com>
      Reported-by: NColin Ian King <colin.king@canonical.com>
      Suggested-by: NColin Ian King <colin.king@canonical.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f3fe412b
    • D
      net: phy: smsc: fix printing too many logs · 6d61f483
      Dejin Zheng 提交于
      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: NKevin Groeneveld <kgroeneveld@gmail.com>
      Signed-off-by: NDejin Zheng <zhengdejin5@gmail.com>
      Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6d61f483
    • F
      MAINTAINERS: update email address for Felix Fietkau · b0c34bde
      Felix Fietkau 提交于
      The old address has been bouncing for a while now
      Signed-off-by: NFelix Fietkau <nbd@nbd.name>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b0c34bde
  3. 21 6月, 2020 4 次提交
    • R
      net: Add MODULE_DESCRIPTION entries to network modules · 67c20de3
      Rob Gill 提交于
      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: NRob Gill <rrobgill@protonmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      67c20de3
    • D
      rxrpc: Fix notification call on completion of discarded calls · 0041cd5a
      David Howells 提交于
      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: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0041cd5a
    • D
      Merge tag 'ieee802154-for-davem-2020-06-19' of... · 7fcaf731
      David S. Miller 提交于
      Merge tag 'ieee802154-for-davem-2020-06-19' of git://git.kernel.org/pub/scm/linux/kernel/git/sschmidt/wpan
      
      Stefan Schmidt says:
      
      ====================
      pull-request: ieee802154 for net 2020-06-19
      
      An update from ieee802154 for your *net* tree.
      
      Just two small maintenance fixes to update references to the new project
      homepage.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7fcaf731
    • H
      tc-testing: update geneve options match in tunnel_key unit tests · 54eeea0d
      Hangbin Liu 提交于
      Since iproute2 commit f72c3ad00f3b ("tc: m_tunnel_key: add options
      support for vxlan"), the geneve opt output use key word "geneve_opts"
      instead of "geneve_opt". To make compatibility for both old and new
      iproute2, let's accept both "geneve_opt" and "geneve_opts".
      Suggested-by: NDavide Caratti <dcaratti@redhat.com>
      Signed-off-by: NHangbin Liu <liuhangbin@gmail.com>
      Reviewed-by: NSimon Horman <simon.horman@netronome.com>
      Tested-by: NDavide Caratti <dcaratti@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      54eeea0d