1. 14 Nov, 2022 1 commit
    • Chuang Wang's avatar
      net: macvlan: Use built-in RCU list checking · 5df1341e
      Chuang Wang authored
      hlist_for_each_entry_rcu() has built-in RCU and lock checking.
      
      Pass cond argument to hlist_for_each_entry_rcu() to silence false
      lockdep warning when CONFIG_PROVE_RCU_LIST is enabled.
      
      Execute as follow:
      
       ip link add link eth0 type macvlan mode source macaddr add <MAC-ADDR>
      
      The rtnl_lock is held when macvlan_hash_lookup_source() or
      macvlan_fill_info_macaddr() are called in the non-RCU read side section.
      So, pass lockdep_rtnl_is_held() to silence false lockdep warning.
      
      Fixes: 79cf79ab
      
       ("macvlan: add source mode")
      Signed-off-by: default avatarChuang Wang <nashuiliang@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5df1341e
  2. 10 Nov, 2022 1 commit
    • Chuang Wang's avatar
      net: macvlan: fix memory leaks of macvlan_common_newlink · 23569b56
      Chuang Wang authored
      kmemleak reports memory leaks in macvlan_common_newlink, as follows:
      
       ip link add link eth0 name .. type macvlan mode source macaddr add
       <MAC-ADDR>
      
      kmemleak reports:
      
      unreferenced object 0xffff8880109bb140 (size 64):
        comm "ip", pid 284, jiffies 4294986150 (age 430.108s)
        hex dump (first 32 bytes):
          00 00 00 00 00 00 00 00 b8 aa 5a 12 80 88 ff ff  ..........Z.....
          80 1b fa 0d 80 88 ff ff 1e ff ac af c7 c1 6b 6b  ..............kk
        backtrace:
          [<ffffffff813e06a7>] kmem_cache_alloc_trace+0x1c7/0x300
          [<ffffffff81b66025>] macvlan_hash_add_source+0x45/0xc0
          [<ffffffff81b66a67>] macvlan_changelink_sources+0xd7/0x170
          [<ffffffff81b6775c>] macvlan_common_newlink+0x38c/0x5a0
          [<ffffffff81b6797e>] macvlan_newlink+0xe/0x20
          [<ffffffff81d97f8f>] __rtnl_newlink+0x7af/0xa50
          [<ffffffff81d98278>] rtnl_newlink+0x48/0x70
          ...
      
      In the scenario where the macvlan mode is configured as 'source',
      macvlan_changelink_sources() will be execured to reconfigure list of
      remote source mac addresses, at the same time, if register_netdevice()
      return an error, the resource generated by macvlan_changelink_sources()
      is not cleaned up.
      
      Using this patch, in the case of an error, it will execute
      macvlan_flush_sources() to ensure that the resource is cleaned up.
      
      Fixes: aa5fd0fb
      
       ("driver: macvlan: Destroy new macvlan port if macvlan_common_newlink failed.")
      Signed-off-by: default avatarChuang Wang <nashuiliang@gmail.com>
      Link: https://lore.kernel.org/r/20221109090735.690500-1-nashuiliang@gmail.com
      
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      23569b56
  3. 14 Oct, 2022 1 commit
  4. 09 Oct, 2022 1 commit
    • Eric Dumazet's avatar
      macvlan: enforce a consistent minimal mtu · b64085b0
      Eric Dumazet authored
      macvlan should enforce a minimal mtu of 68, even at link creation.
      
      This patch avoids the current behavior (which could lead to crashes
      in ipv6 stack if the link is brought up)
      
      $ ip link add macvlan1 link eno1 mtu 8 type macvlan  # This should fail !
      $ ip link sh dev macvlan1
      5: macvlan1@eno1: <BROADCAST,MULTICAST> mtu 8 qdisc noop
          state DOWN mode DEFAULT group default qlen 1000
          link/ether 02:47:6c:24:74:82 brd ff:ff:ff:ff:ff:ff
      $ ip link set macvlan1 mtu 67
      Error: mtu less than device minimum.
      $ ip link set macvlan1 mtu 68
      $ ip link set macvlan1 mtu 8
      Error: mtu less than device minimum.
      
      Fixes: 91572088
      
       ("net: use core MTU range checking in core net infra")
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b64085b0
  5. 31 Aug, 2022 1 commit
  6. 10 Jun, 2022 2 commits
  7. 09 May, 2022 1 commit
  8. 06 May, 2022 1 commit
  9. 13 Apr, 2022 1 commit
    • Martin Willi's avatar
      macvlan: Fix leaking skb in source mode with nodst option · e16b8598
      Martin Willi authored
      The MACVLAN receive handler clones skbs to all matching source MACVLAN
      interfaces, before it passes the packet along to match on destination
      based MACVLANs.
      
      When using the MACVLAN nodst mode, passing the packet to destination based
      MACVLANs is omitted and the handler returns with RX_HANDLER_CONSUMED.
      However, the passed skb is not freed, leaking for any packet processed
      with the nodst option.
      
      Properly free the skb when consuming packets to fix that leak.
      
      Fixes: 427f0c8c
      
       ("macvlan: Add nodst option to macvlan type source")
      Signed-off-by: default avatarMartin Willi <martin@strongswan.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e16b8598
  10. 14 Mar, 2022 2 commits
  11. 12 Mar, 2022 1 commit
  12. 04 Mar, 2022 1 commit
  13. 14 Feb, 2022 1 commit
    • Sebastian Andrzej Siewior's avatar
      net: dev: Makes sure netif_rx() can be invoked in any context. · baebdf48
      Sebastian Andrzej Siewior authored
      Dave suggested a while ago (eleven years by now) "Let's make netif_rx()
      work in all contexts and get rid of netif_rx_ni()". Eric agreed and
      pointed out that modern devices should use netif_receive_skb() to avoid
      the overhead.
      In the meantime someone added another variant, netif_rx_any_context(),
      which behaves as suggested.
      
      netif_rx() must be invoked with disabled bottom halves to ensure that
      pending softirqs, which were raised within the function, are handled.
      netif_rx_ni() can be invoked only from process context (bottom halves
      must be enabled) because the function handles pending softirqs without
      checking if bottom halves were disabled or not.
      netif_rx_any_context() invokes on the former functions by checking
      in_interrupts().
      
      netif_rx() could be taught to handle both cases (disabled and enabled
      bottom halves) by simply disabling bottom halves while invoking
      netif_rx_internal(). The local_bh_enable() invocation will then invoke
      pending softirqs only if the BH-disable counter drops to zero.
      
      Eric is concerned about the overhead of BH-disable+enable especially in
      regard to the loopback driver. As critical as this driver is, it will
      receive a shortcut to avoid the additional overhead which is not needed.
      
      Add a local_bh_disable() section in netif_rx() to ensure softirqs are
      handled if needed.
      Provide __netif_rx() which does not disable BH and has a lockdep assert
      to ensure that interrupts are disabled. Use this shortcut in the
      loopback driver and in drivers/net/*.c.
      Make netif_rx_ni() and netif_rx_any_context() invoke netif_rx() so they
      can be removed once they are no more users left.
      
      Link: https://lkml.kernel.org/r/20100415.020246.218622820.davem@davemloft.net
      
      Signed-off-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Reviewed-by: default avatarToke Høiland-Jørgensen <toke@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      baebdf48
  14. 23 Nov, 2021 1 commit
    • Jakub Kicinski's avatar
      net: remove .ndo_change_proto_down · 2106efda
      Jakub Kicinski authored
      
      .ndo_change_proto_down was added seemingly to enable out-of-tree
      implementations. Over 2.5yrs later we still have no real users
      upstream. Hardwire the generic implementation for now, we can
      revert once real users materialize. (rocker is a test vehicle,
      not a user.)
      
      We need to drop the optimization on the sysfs side, because
      unlike ndos priv_flags will be changed at runtime, so we'd
      need READ_ONCE/WRITE_ONCE everywhere..
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2106efda
  15. 22 Nov, 2021 2 commits
  16. 24 Oct, 2021 1 commit
  17. 02 Oct, 2021 2 commits
  18. 27 Jul, 2021 1 commit
    • Arnd Bergmann's avatar
      dev_ioctl: split out ndo_eth_ioctl · a7605370
      Arnd Bergmann authored
      
      Most users of ndo_do_ioctl are ethernet drivers that implement
      the MII commands SIOCGMIIPHY/SIOCGMIIREG/SIOCSMIIREG, or hardware
      timestamping with SIOCSHWTSTAMP/SIOCGHWTSTAMP.
      
      Separate these from the few drivers that use ndo_do_ioctl to
      implement SIOCBOND, SIOCBR and SIOCWANDEV commands.
      
      This is a purely cosmetic change intended to help readers find
      their way through the implementation.
      
      Cc: Doug Ledford <dledford@redhat.com>
      Cc: Jason Gunthorpe <jgg@ziepe.ca>
      Cc: Jay Vosburgh <j.vosburgh@gmail.com>
      Cc: Veaceslav Falico <vfalico@gmail.com>
      Cc: Andy Gospodarek <andy@greyhouse.net>
      Cc: Andrew Lunn <andrew@lunn.ch>
      Cc: Vivien Didelot <vivien.didelot@gmail.com>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Cc: Vladimir Oltean <olteanv@gmail.com>
      Cc: Leon Romanovsky <leon@kernel.org>
      Cc: linux-rdma@vger.kernel.org
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarJason Gunthorpe <jgg@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a7605370
  19. 02 Jun, 2021 1 commit
  20. 27 Apr, 2021 1 commit
  21. 26 Apr, 2021 1 commit
    • Jethro Beekman's avatar
      macvlan: Add nodst option to macvlan type source · 427f0c8c
      Jethro Beekman authored
      
      The default behavior for source MACVLAN is to duplicate packets to
      appropriate type source devices, and then do the normal destination MACVLAN
      flow. This patch adds an option to skip destination MACVLAN processing if
      any matching source MACVLAN device has the option set.
      
      This allows setting up a "catch all" device for source MACVLAN: create one
      or more devices with type source nodst, and one device with e.g. type vepa,
      and incoming traffic will be received on exactly one device.
      
      v2: netdev wants non-standard line length
      Signed-off-by: default avatarJethro Beekman <kernel@jbeekman.nl>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      427f0c8c
  22. 06 Jan, 2021 1 commit
  23. 03 Dec, 2020 1 commit
    • Thomas Karlsson's avatar
      macvlan: Support for high multicast packet rate · d4bff72c
      Thomas Karlsson authored
      
      Background:
      Broadcast and multicast packages are enqueued for later processing.
      This queue was previously hardcoded to 1000.
      
      This proved insufficient for handling very high packet rates.
      This resulted in packet drops for multicast.
      While at the same time unicast worked fine.
      
      The change:
      This patch make the queue length adjustable to accommodate
      for environments with very high multicast packet rate.
      But still keeps the default value of 1000 unless specified.
      
      The queue length is specified as a request per macvlan
      using the IFLA_MACVLAN_BC_QUEUE_LEN parameter.
      
      The actual used queue length will then be the maximum of
      any macvlan connected to the same port. The actual used
      queue length for the port can be retrieved (read only)
      by the IFLA_MACVLAN_BC_QUEUE_LEN_USED parameter for verification.
      
      This will be followed up by a patch to iproute2
      in order to adjust the parameter from userspace.
      Signed-off-by: default avatarThomas Karlsson <thomas.karlsson@paneda.se>
      Link: https://lore.kernel.org/r/dd4673b2-7eab-edda-6815-85c67ce87f63@paneda.se
      
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      d4bff72c
  24. 07 Nov, 2020 1 commit
  25. 04 Nov, 2020 1 commit
  26. 23 Aug, 2020 1 commit
  27. 18 Aug, 2020 1 commit
    • Alvin Šipraga's avatar
      macvlan: validate setting of multiple remote source MAC addresses · 8b61fba5
      Alvin Šipraga authored
      
      Remote source MAC addresses can be set on a 'source mode' macvlan
      interface via the IFLA_MACVLAN_MACADDR_DATA attribute. This commit
      tightens the validation of these MAC addresses to match the validation
      already performed when setting or adding a single MAC address via the
      IFLA_MACVLAN_MACADDR attribute.
      
      iproute2 uses IFLA_MACVLAN_MACADDR_DATA for its 'macvlan macaddr set'
      command, and IFLA_MACVLAN_MACADDR for its 'macvlan macaddr add' command,
      which demonstrates the inconsistent behaviour that this commit
      addresses:
      
       # ip link add link eth0 name macvlan0 type macvlan mode source
       # ip link set link dev macvlan0 type macvlan macaddr add 01:00:00:00:00:00
       RTNETLINK answers: Cannot assign requested address
       # ip link set link dev macvlan0 type macvlan macaddr set 01:00:00:00:00:00
       # ip -d link show macvlan0
       5: macvlan0@eth0: <BROADCAST,MULTICAST,DYNAMIC,UP,LOWER_UP> mtu 1500 ...
           link/ether 2e:ac:fd:2d:69:f8 brd ff:ff:ff:ff:ff:ff promiscuity 0
           macvlan mode source remotes (1) 01:00:00:00:00:00 numtxqueues 1 ...
      
      With this change, the 'set' command will (rightly) fail in the same way
      as the 'add' command.
      Signed-off-by: default avatarAlvin Šipraga <alsi@bang-olufsen.dk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8b61fba5
  28. 29 Jun, 2020 1 commit
  29. 09 Jun, 2020 1 commit
    • Cong Wang's avatar
      net: change addr_list_lock back to static key · 845e0ebb
      Cong Wang authored
      The dynamic key update for addr_list_lock still causes troubles,
      for example the following race condition still exists:
      
      CPU 0:				CPU 1:
      (RCU read lock)			(RTNL lock)
      dev_mc_seq_show()		netdev_update_lockdep_key()
      				  -> lockdep_unregister_key()
       -> netif_addr_lock_bh()
      
      because lockdep doesn't provide an API to update it atomically.
      Therefore, we have to move it back to static keys and use subclass
      for nest locking like before.
      
      In commit 1a33e10e ("net: partially revert dynamic lockdep key
      changes"), I already reverted most parts of commit ab92d68f
      ("net: core: add generic lockdep keys").
      
      This patch reverts the rest and also part of commit f3b0a18b
      
      
      ("net: remove unnecessary variables and callback"). After this
      patch, addr_list_lock changes back to using static keys and
      subclasses to satisfy lockdep. Thanks to dev->lower_level, we do
      not have to change back to ->ndo_get_lock_subclass().
      
      And hopefully this reduces some syzbot lockdep noises too.
      
      Reported-by: syzbot+f3a0e80c34b3fc28ac5e@syzkaller.appspotmail.com
      Cc: Taehee Yoo <ap420073@gmail.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      845e0ebb
  30. 27 May, 2020 1 commit
    • Alexander Sverdlin's avatar
      macvlan: Skip loopback packets in RX handler · 81f3dc93
      Alexander Sverdlin authored
      
      Ignore loopback-originatig packets soon enough and don't try to process L2
      header where it doesn't exist. The very similar br_handle_frame() in bridge
      code performs exactly the same check.
      
      This is an example of such ICMPv6 packet:
      
      skb len=96 headroom=40 headlen=96 tailroom=56
      mac=(40,0) net=(40,40) trans=80
      shinfo(txflags=0 nr_frags=0 gso(size=0 type=0 segs=0))
      csum(0xae2e9a2f ip_summed=1 complete_sw=0 valid=0 level=0)
      hash(0xc97ebd88 sw=1 l4=1) proto=0x86dd pkttype=5 iif=24
      dev name=etha01.212 feat=0x0x0000000040005000
      skb headroom: 00000000: 00 7c 86 52 84 88 ff ff 00 00 00 00 00 00 08 00
      skb headroom: 00000010: 45 00 00 9e 5d 5c 40 00 40 11 33 33 00 00 00 01
      skb headroom: 00000020: 02 40 43 80 00 00 86 dd
      skb linear:   00000000: 60 09 88 bd 00 38 3a ff fe 80 00 00 00 00 00 00
      skb linear:   00000010: 00 40 43 ff fe 80 00 00 ff 02 00 00 00 00 00 00
      skb linear:   00000020: 00 00 00 00 00 00 00 01 86 00 61 00 40 00 00 2d
      skb linear:   00000030: 00 00 00 00 00 00 00 00 03 04 40 e0 00 00 01 2c
      skb linear:   00000040: 00 00 00 78 00 00 00 00 fd 5f 42 68 23 87 a8 81
      skb linear:   00000050: 00 00 00 00 00 00 00 00 01 01 02 40 43 80 00 00
      skb tailroom: 00000000: ...
      skb tailroom: 00000010: ...
      skb tailroom: 00000020: ...
      skb tailroom: 00000030: ...
      
      Call Trace, how it happens exactly:
       ...
       macvlan_handle_frame+0x321/0x425 [macvlan]
       ? macvlan_forward_source+0x110/0x110 [macvlan]
       __netif_receive_skb_core+0x545/0xda0
       ? enqueue_task_fair+0xe5/0x8e0
       ? __netif_receive_skb_one_core+0x36/0x70
       __netif_receive_skb_one_core+0x36/0x70
       process_backlog+0x97/0x140
       net_rx_action+0x1eb/0x350
       ? __hrtimer_run_queues+0x136/0x2e0
       __do_softirq+0xe3/0x383
       do_softirq_own_stack+0x2a/0x40
       </IRQ>
       do_softirq.part.4+0x4e/0x50
       netif_rx_ni+0x60/0xd0
       dev_loopback_xmit+0x83/0xf0
       ip6_finish_output2+0x575/0x590 [ipv6]
       ? ip6_cork_release.isra.1+0x64/0x90 [ipv6]
       ? __ip6_make_skb+0x38d/0x680 [ipv6]
       ? ip6_output+0x6c/0x140 [ipv6]
       ip6_output+0x6c/0x140 [ipv6]
       ip6_send_skb+0x1e/0x60 [ipv6]
       rawv6_sendmsg+0xc4b/0xe10 [ipv6]
       ? proc_put_long+0xd0/0xd0
       ? rw_copy_check_uvector+0x4e/0x110
       ? sock_sendmsg+0x36/0x40
       sock_sendmsg+0x36/0x40
       ___sys_sendmsg+0x2b6/0x2d0
       ? proc_dointvec+0x23/0x30
       ? addrconf_sysctl_forward+0x8d/0x250 [ipv6]
       ? dev_forward_change+0x130/0x130 [ipv6]
       ? _raw_spin_unlock+0x12/0x30
       ? proc_sys_call_handler.isra.14+0x9f/0x110
       ? __call_rcu+0x213/0x510
       ? get_max_files+0x10/0x10
       ? trace_hardirqs_on+0x2c/0xe0
       ? __sys_sendmsg+0x63/0xa0
       __sys_sendmsg+0x63/0xa0
       do_syscall_64+0x6c/0x1e0
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      Signed-off-by: default avatarAlexander Sverdlin <alexander.sverdlin@nokia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      81f3dc93
  31. 08 May, 2020 1 commit
  32. 04 May, 2020 1 commit
  33. 23 Apr, 2020 1 commit
    • Wei Yongjun's avatar
      macvlan: silence RCU list debugging warning · 58e64a31
      Wei Yongjun authored
      
      macvlan_hash_lookup() uses list_for_each_entry_rcu() for traversing
      should either under RCU in fast path or the protection of rtnl_mutex.
      
      In the case of holding RTNL, we should add the corresponding lockdep
      expression to silence the following false-positive warning:
      
      =============================
      WARNING: suspicious RCU usage
      5.7.0-rc1-next-20200416-00003-ga3b8d28bc #1 Not tainted
      -----------------------------
      drivers/net/macvlan.c:126 RCU-list traversed in non-reader section!!
      Signed-off-by: default avatarWei Yongjun <weiyongjun1@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      58e64a31
  34. 21 Apr, 2020 1 commit
    • Taehee Yoo's avatar
      macvlan: fix null dereference in macvlan_device_event() · 4dee15b4
      Taehee Yoo authored
      In the macvlan_device_event(), the list_first_entry_or_null() is used.
      This function could return null pointer if there is no node.
      But, the macvlan module doesn't check the null pointer.
      So, null-ptr-deref would occur.
      
            bond0
              |
         +----+-----+
         |          |
      macvlan0   macvlan1
         |          |
       dummy0     dummy1
      
      The problem scenario.
      If dummy1 is removed,
      1. ->dellink() of dummy1 is called.
      2. NETDEV_UNREGISTER of dummy1 notification is sent to macvlan module.
      3. ->dellink() of macvlan1 is called.
      4. NETDEV_UNREGISTER of macvlan1 notification is sent to bond module.
      5. __bond_release_one() is called and it internally calls
         dev_set_mac_address().
      6. dev_set_mac_address() calls the ->ndo_set_mac_address() of macvlan1,
         which is macvlan_set_mac_address().
      7. macvlan_set_mac_address() calls the dev_set_mac_address() with dummy1.
      8. NETDEV_CHANGEADDR of dummy1 is sent to macvlan module.
      9. In the macvlan_device_event(), it calls list_first_entry_or_null().
      At this point, dummy1 and macvlan1 were removed.
      So, list_first_entry_or_null() will return NULL.
      
      Test commands:
          ip netns add nst
          ip netns exec nst ip link add bond0 type bond
          for i in {0..10}
          do
              ip netns exec nst ip link add dummy$i type dummy
      	ip netns exec nst ip link add macvlan$i link dummy$i \
      		type macvlan mode passthru
      	ip netns exec nst ip link set macvlan$i master bond0
          done
          ip netns del nst
      
      Splat looks like:
      [   40.585687][  T146] general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP DEI
      [   40.587249][  T146] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
      [   40.588342][  T146] CPU: 1 PID: 146 Comm: kworker/u8:2 Not tainted 5.7.0-rc1+ #532
      [   40.589299][  T146] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
      [   40.590469][  T146] Workqueue: netns cleanup_net
      [   40.591045][  T146] RIP: 0010:macvlan_device_event+0x4e2/0x900 [macvlan]
      [   40.591905][  T146] Code: 00 00 00 00 00 fc ff df 80 3c 06 00 0f 85 45 02 00 00 48 89 da 48 b8 00 00 00 00 00 fc ff d2
      [   40.594126][  T146] RSP: 0018:ffff88806116f4a0 EFLAGS: 00010246
      [   40.594783][  T146] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
      [   40.595653][  T146] RDX: 0000000000000000 RSI: ffff88806547ddd8 RDI: ffff8880540f1360
      [   40.596495][  T146] RBP: ffff88804011a808 R08: fffffbfff4fb8421 R09: fffffbfff4fb8421
      [   40.597377][  T146] R10: ffffffffa7dc2107 R11: 0000000000000000 R12: 0000000000000008
      [   40.598186][  T146] R13: ffff88804011a000 R14: ffff8880540f1000 R15: 1ffff1100c22de9a
      [   40.599012][  T146] FS:  0000000000000000(0000) GS:ffff888067800000(0000) knlGS:0000000000000000
      [   40.600004][  T146] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   40.600665][  T146] CR2: 00005572d3a807b8 CR3: 000000005fcf4003 CR4: 00000000000606e0
      [   40.601485][  T146] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [   40.602461][  T146] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [   40.603443][  T146] Call Trace:
      [   40.603871][  T146]  ? nf_tables_dump_setelem+0xa0/0xa0 [nf_tables]
      [   40.604587][  T146]  ? macvlan_uninit+0x100/0x100 [macvlan]
      [   40.605212][  T146]  ? __module_text_address+0x13/0x140
      [   40.605842][  T146]  notifier_call_chain+0x90/0x160
      [   40.606477][  T146]  dev_set_mac_address+0x28e/0x3f0
      [   40.607117][  T146]  ? netdev_notify_peers+0xc0/0xc0
      [   40.607762][  T146]  ? __module_text_address+0x13/0x140
      [   40.608440][  T146]  ? notifier_call_chain+0x90/0x160
      [   40.609097][  T146]  ? dev_set_mac_address+0x1f0/0x3f0
      [   40.609758][  T146]  dev_set_mac_address+0x1f0/0x3f0
      [   40.610402][  T146]  ? __local_bh_enable_ip+0xe9/0x1b0
      [   40.611071][  T146]  ? bond_hw_addr_flush+0x77/0x100 [bonding]
      [   40.611823][  T146]  ? netdev_notify_peers+0xc0/0xc0
      [   40.612461][  T146]  ? bond_hw_addr_flush+0x77/0x100 [bonding]
      [   40.613213][  T146]  ? bond_hw_addr_flush+0x77/0x100 [bonding]
      [   40.613963][  T146]  ? __local_bh_enable_ip+0xe9/0x1b0
      [   40.614631][  T146]  ? bond_time_in_interval.isra.31+0x90/0x90 [bonding]
      [   40.615484][  T146]  ? __bond_release_one+0x9f0/0x12c0 [bonding]
      [   40.616230][  T146]  __bond_release_one+0x9f0/0x12c0 [bonding]
      [   40.616949][  T146]  ? bond_enslave+0x47c0/0x47c0 [bonding]
      [   40.617642][  T146]  ? lock_downgrade+0x730/0x730
      [   40.618218][  T146]  ? check_flags.part.42+0x450/0x450
      [   40.618850][  T146]  ? __mutex_unlock_slowpath+0xd0/0x670
      [   40.619519][  T146]  ? trace_hardirqs_on+0x30/0x180
      [   40.620117][  T146]  ? wait_for_completion+0x250/0x250
      [   40.620754][  T146]  bond_netdev_event+0x822/0x970 [bonding]
      [   40.621460][  T146]  ? __module_text_address+0x13/0x140
      [   40.622097][  T146]  notifier_call_chain+0x90/0x160
      [   40.622806][  T146]  rollback_registered_many+0x660/0xcf0
      [   40.623522][  T146]  ? netif_set_real_num_tx_queues+0x780/0x780
      [   40.624290][  T146]  ? notifier_call_chain+0x90/0x160
      [   40.624957][  T146]  ? netdev_upper_dev_unlink+0x114/0x180
      [   40.625686][  T146]  ? __netdev_adjacent_dev_unlink_neighbour+0x30/0x30
      [   40.626421][  T146]  ? mutex_is_locked+0x13/0x50
      [   40.627016][  T146]  ? unregister_netdevice_queue+0xf2/0x240
      [   40.627663][  T146]  unregister_netdevice_many.part.134+0x13/0x1b0
      [   40.628362][  T146]  default_device_exit_batch+0x2d9/0x390
      [   40.628987][  T146]  ? unregister_netdevice_many+0x40/0x40
      [   40.629615][  T146]  ? dev_change_net_namespace+0xcb0/0xcb0
      [   40.630279][  T146]  ? prepare_to_wait_exclusive+0x2e0/0x2e0
      [   40.630943][  T146]  ? ops_exit_list.isra.9+0x97/0x140
      [   40.631554][  T146]  cleanup_net+0x441/0x890
      [ ... ]
      
      Fixes: e289fd28
      
       ("macvlan: fix the problem when mac address changes for passthru mode")
      Reported-by: syzbot+5035b1f9dc7ea4558d5a@syzkaller.appspotmail.com
      Signed-off-by: default avatarTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4dee15b4
  35. 10 Mar, 2020 1 commit
    • Mahesh Bandewar's avatar
      macvlan: add cond_resched() during multicast processing · ce9a4186
      Mahesh Bandewar authored
      The Rx bound multicast packets are deferred to a workqueue and
      macvlan can also suffer from the same attack that was discovered
      by Syzbot for IPvlan. This solution is not as effective as in
      IPvlan. IPvlan defers all (Tx and Rx) multicast packet processing
      to a workqueue while macvlan does this way only for the Rx. This
      fix should address the Rx codition to certain extent.
      
      Tx is still suseptible. Tx multicast processing happens when
      .ndo_start_xmit is called, hence we cannot add cond_resched().
      However, it's not that severe since the user which is generating
       / flooding will be affected the most.
      
      Fixes: 412ca155
      
       ("macvlan: Move broadcasts into a work queue")
      Signed-off-by: default avatarMahesh Bandewar <maheshb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ce9a4186
  36. 16 Jan, 2020 1 commit