1. 02 6月, 2021 1 次提交
  2. 28 4月, 2021 1 次提交
  3. 26 4月, 2021 1 次提交
    • J
      macvlan: Add nodst option to macvlan type source · 427f0c8c
      Jethro Beekman 提交于
      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: NJethro Beekman <kernel@jbeekman.nl>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      427f0c8c
  4. 06 1月, 2021 1 次提交
  5. 04 12月, 2020 1 次提交
    • T
      macvlan: Support for high multicast packet rate · d4bff72c
      Thomas Karlsson 提交于
      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: NThomas Karlsson <thomas.karlsson@paneda.se>
      Link: https://lore.kernel.org/r/dd4673b2-7eab-edda-6815-85c67ce87f63@paneda.seSigned-off-by: NJakub Kicinski <kuba@kernel.org>
      d4bff72c
  6. 08 11月, 2020 1 次提交
  7. 04 11月, 2020 1 次提交
  8. 24 8月, 2020 1 次提交
  9. 19 8月, 2020 1 次提交
    • A
      macvlan: validate setting of multiple remote source MAC addresses · 8b61fba5
      Alvin Šipraga 提交于
      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: NAlvin Šipraga <alsi@bang-olufsen.dk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8b61fba5
  10. 29 6月, 2020 1 次提交
  11. 10 6月, 2020 1 次提交
    • C
      net: change addr_list_lock back to static key · 845e0ebb
      Cong Wang 提交于
      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: NCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      845e0ebb
  12. 27 5月, 2020 1 次提交
    • A
      macvlan: Skip loopback packets in RX handler · 81f3dc93
      Alexander Sverdlin 提交于
      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: NAlexander Sverdlin <alexander.sverdlin@nokia.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      81f3dc93
  13. 08 5月, 2020 1 次提交
  14. 05 5月, 2020 1 次提交
  15. 23 4月, 2020 1 次提交
    • W
      macvlan: silence RCU list debugging warning · 58e64a31
      Wei Yongjun 提交于
      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: NWei Yongjun <weiyongjun1@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      58e64a31
  16. 22 4月, 2020 1 次提交
    • T
      macvlan: fix null dereference in macvlan_device_event() · 4dee15b4
      Taehee Yoo 提交于
      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: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4dee15b4
  17. 10 3月, 2020 1 次提交
    • M
      macvlan: add cond_resched() during multicast processing · ce9a4186
      Mahesh Bandewar 提交于
      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: NMahesh Bandewar <maheshb@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ce9a4186
  18. 16 1月, 2020 1 次提交
  19. 09 1月, 2020 1 次提交
    • E
      macvlan: do not assume mac_header is set in macvlan_broadcast() · 96cc4b69
      Eric Dumazet 提交于
      Use of eth_hdr() in tx path is error prone.
      
      Many drivers call skb_reset_mac_header() before using it,
      but others do not.
      
      Commit 6d1ccff6 ("net: reset mac header in dev_start_xmit()")
      attempted to fix this generically, but commit d346a3fa
      ("packet: introduce PACKET_QDISC_BYPASS socket option") brought
      back the macvlan bug.
      
      Lets add a new helper, so that tx paths no longer have
      to call skb_reset_mac_header() only to get a pointer
      to skb->data.
      
      Hopefully we will be able to revert 6d1ccff6
      ("net: reset mac header in dev_start_xmit()") and save few cycles
      in transmit fast path.
      
      BUG: KASAN: use-after-free in __get_unaligned_cpu32 include/linux/unaligned/packed_struct.h:19 [inline]
      BUG: KASAN: use-after-free in mc_hash drivers/net/macvlan.c:251 [inline]
      BUG: KASAN: use-after-free in macvlan_broadcast+0x547/0x620 drivers/net/macvlan.c:277
      Read of size 4 at addr ffff8880a4932401 by task syz-executor947/9579
      
      CPU: 0 PID: 9579 Comm: syz-executor947 Not tainted 5.5.0-rc4-syzkaller #0
      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+0x197/0x210 lib/dump_stack.c:118
       print_address_description.constprop.0.cold+0xd4/0x30b mm/kasan/report.c:374
       __kasan_report.cold+0x1b/0x41 mm/kasan/report.c:506
       kasan_report+0x12/0x20 mm/kasan/common.c:639
       __asan_report_load_n_noabort+0xf/0x20 mm/kasan/generic_report.c:145
       __get_unaligned_cpu32 include/linux/unaligned/packed_struct.h:19 [inline]
       mc_hash drivers/net/macvlan.c:251 [inline]
       macvlan_broadcast+0x547/0x620 drivers/net/macvlan.c:277
       macvlan_queue_xmit drivers/net/macvlan.c:520 [inline]
       macvlan_start_xmit+0x402/0x77f drivers/net/macvlan.c:559
       __netdev_start_xmit include/linux/netdevice.h:4447 [inline]
       netdev_start_xmit include/linux/netdevice.h:4461 [inline]
       dev_direct_xmit+0x419/0x630 net/core/dev.c:4079
       packet_direct_xmit+0x1a9/0x250 net/packet/af_packet.c:240
       packet_snd net/packet/af_packet.c:2966 [inline]
       packet_sendmsg+0x260d/0x6220 net/packet/af_packet.c:2991
       sock_sendmsg_nosec net/socket.c:639 [inline]
       sock_sendmsg+0xd7/0x130 net/socket.c:659
       __sys_sendto+0x262/0x380 net/socket.c:1985
       __do_sys_sendto net/socket.c:1997 [inline]
       __se_sys_sendto net/socket.c:1993 [inline]
       __x64_sys_sendto+0xe1/0x1a0 net/socket.c:1993
       do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x442639
      Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 5b 10 fc ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007ffc13549e08 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
      RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000442639
      RDX: 000000000000000e RSI: 0000000020000080 RDI: 0000000000000003
      RBP: 0000000000000004 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
      R13: 0000000000403bb0 R14: 0000000000000000 R15: 0000000000000000
      
      Allocated by task 9389:
       save_stack+0x23/0x90 mm/kasan/common.c:72
       set_track mm/kasan/common.c:80 [inline]
       __kasan_kmalloc mm/kasan/common.c:513 [inline]
       __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:486
       kasan_kmalloc+0x9/0x10 mm/kasan/common.c:527
       __do_kmalloc mm/slab.c:3656 [inline]
       __kmalloc+0x163/0x770 mm/slab.c:3665
       kmalloc include/linux/slab.h:561 [inline]
       tomoyo_realpath_from_path+0xc5/0x660 security/tomoyo/realpath.c:252
       tomoyo_get_realpath security/tomoyo/file.c:151 [inline]
       tomoyo_path_perm+0x230/0x430 security/tomoyo/file.c:822
       tomoyo_inode_getattr+0x1d/0x30 security/tomoyo/tomoyo.c:129
       security_inode_getattr+0xf2/0x150 security/security.c:1222
       vfs_getattr+0x25/0x70 fs/stat.c:115
       vfs_statx_fd+0x71/0xc0 fs/stat.c:145
       vfs_fstat include/linux/fs.h:3265 [inline]
       __do_sys_newfstat+0x9b/0x120 fs/stat.c:378
       __se_sys_newfstat fs/stat.c:375 [inline]
       __x64_sys_newfstat+0x54/0x80 fs/stat.c:375
       do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Freed by task 9389:
       save_stack+0x23/0x90 mm/kasan/common.c:72
       set_track mm/kasan/common.c:80 [inline]
       kasan_set_free_info mm/kasan/common.c:335 [inline]
       __kasan_slab_free+0x102/0x150 mm/kasan/common.c:474
       kasan_slab_free+0xe/0x10 mm/kasan/common.c:483
       __cache_free mm/slab.c:3426 [inline]
       kfree+0x10a/0x2c0 mm/slab.c:3757
       tomoyo_realpath_from_path+0x1a7/0x660 security/tomoyo/realpath.c:289
       tomoyo_get_realpath security/tomoyo/file.c:151 [inline]
       tomoyo_path_perm+0x230/0x430 security/tomoyo/file.c:822
       tomoyo_inode_getattr+0x1d/0x30 security/tomoyo/tomoyo.c:129
       security_inode_getattr+0xf2/0x150 security/security.c:1222
       vfs_getattr+0x25/0x70 fs/stat.c:115
       vfs_statx_fd+0x71/0xc0 fs/stat.c:145
       vfs_fstat include/linux/fs.h:3265 [inline]
       __do_sys_newfstat+0x9b/0x120 fs/stat.c:378
       __se_sys_newfstat fs/stat.c:375 [inline]
       __x64_sys_newfstat+0x54/0x80 fs/stat.c:375
       do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      The buggy address belongs to the object at ffff8880a4932000
       which belongs to the cache kmalloc-4k of size 4096
      The buggy address is located 1025 bytes inside of
       4096-byte region [ffff8880a4932000, ffff8880a4933000)
      The buggy address belongs to the page:
      page:ffffea0002924c80 refcount:1 mapcount:0 mapping:ffff8880aa402000 index:0x0 compound_mapcount: 0
      raw: 00fffe0000010200 ffffea0002846208 ffffea00028f3888 ffff8880aa402000
      raw: 0000000000000000 ffff8880a4932000 0000000100000001 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
       ffff8880a4932300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff8880a4932380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      >ffff8880a4932400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                         ^
       ffff8880a4932480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff8880a4932500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      
      Fixes: b863ceb7 ("[NET]: Add macvlan driver")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      96cc4b69
  20. 26 12月, 2019 1 次提交
  21. 26 11月, 2019 1 次提交
    • M
      macvlan: schedule bc_work even if error · 1d7ea556
      Menglong Dong 提交于
      While enqueueing a broadcast skb to port->bc_queue, schedule_work()
      is called to add port->bc_work, which processes the skbs in
      bc_queue, to "events" work queue. If port->bc_queue is full, the
      skb will be discarded and schedule_work(&port->bc_work) won't be
      called. However, if port->bc_queue is full and port->bc_work is not
      running or pending, port->bc_queue will keep full and schedule_work()
      won't be called any more, and all broadcast skbs to macvlan will be
      discarded. This case can happen:
      
      macvlan_process_broadcast() is the pending function of port->bc_work,
      it moves all the skbs in port->bc_queue to the queue "list", and
      processes the skbs in "list". During this, new skbs will keep being
      added to port->bc_queue in macvlan_broadcast_enqueue(), and
      port->bc_queue may already full when macvlan_process_broadcast()
      return. This may happen, especially when there are a lot of real-time
      threads and the process is preempted.
      
      Fix this by calling schedule_work(&port->bc_work) even if
      port->bc_work is full in macvlan_broadcast_enqueue().
      
      Fixes: 412ca155 ("macvlan: Move broadcasts into a work queue")
      Signed-off-by: NMenglong Dong <dong.menglong@zte.com.cn>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1d7ea556
  22. 25 10月, 2019 2 次提交
    • T
      net: remove unnecessary variables and callback · f3b0a18b
      Taehee Yoo 提交于
      This patch removes variables and callback these are related to the nested
      device structure.
      devices that can be nested have their own nest_level variable that
      represents the depth of nested devices.
      In the previous patch, new {lower/upper}_level variables are added and
      they replace old private nest_level variable.
      So, this patch removes all 'nest_level' variables.
      
      In order to avoid lockdep warning, ->ndo_get_lock_subclass() was added
      to get lockdep subclass value, which is actually lower nested depth value.
      But now, they use the dynamic lockdep key to avoid lockdep warning instead
      of the subclass.
      So, this patch removes ->ndo_get_lock_subclass() callback.
      Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f3b0a18b
    • T
      net: core: add generic lockdep keys · ab92d68f
      Taehee Yoo 提交于
      Some interface types could be nested.
      (VLAN, BONDING, TEAM, MACSEC, MACVLAN, IPVLAN, VIRT_WIFI, VXLAN, etc..)
      These interface types should set lockdep class because, without lockdep
      class key, lockdep always warn about unexisting circular locking.
      
      In the current code, these interfaces have their own lockdep class keys and
      these manage itself. So that there are so many duplicate code around the
      /driver/net and /net/.
      This patch adds new generic lockdep keys and some helper functions for it.
      
      This patch does below changes.
      a) Add lockdep class keys in struct net_device
         - qdisc_running, xmit, addr_list, qdisc_busylock
         - these keys are used as dynamic lockdep key.
      b) When net_device is being allocated, lockdep keys are registered.
         - alloc_netdev_mqs()
      c) When net_device is being free'd llockdep keys are unregistered.
         - free_netdev()
      d) Add generic lockdep key helper function
         - netdev_register_lockdep_key()
         - netdev_unregister_lockdep_key()
         - netdev_update_lockdep_key()
      e) Remove unnecessary generic lockdep macro and functions
      f) Remove unnecessary lockdep code of each interfaces.
      
      After this patch, each interface modules don't need to maintain
      their lockdep keys.
      Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ab92d68f
  23. 31 5月, 2019 1 次提交
  24. 29 5月, 2019 1 次提交
  25. 21 5月, 2019 1 次提交
    • G
      macvlan: Mark expected switch fall-through · 02596252
      Gustavo A. R. Silva 提交于
      In preparation to enabling -Wimplicit-fallthrough, mark switch
      cases where we are expecting to fall through.
      
      This patch fixes the following warning:
      
      drivers/net/macvlan.c: In function ‘macvlan_do_ioctl’:
      drivers/net/macvlan.c:839:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
         if (!net_eq(dev_net(dev), &init_net))
            ^
      drivers/net/macvlan.c:841:2: note: here
        case SIOCGHWTSTAMP:
        ^~~~
      
      Warning level 3 was used: -Wimplicit-fallthrough=3
      
      This patch is part of the ongoing efforts to enable
      -Wimplicit-fallthrough.
      Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      02596252
  26. 10 5月, 2019 1 次提交
  27. 28 4月, 2019 1 次提交
    • M
      netlink: make nla_nest_start() add NLA_F_NESTED flag · ae0be8de
      Michal Kubecek 提交于
      Even if the NLA_F_NESTED flag was introduced more than 11 years ago, most
      netlink based interfaces (including recently added ones) are still not
      setting it in kernel generated messages. Without the flag, message parsers
      not aware of attribute semantics (e.g. wireshark dissector or libmnl's
      mnl_nlmsg_fprintf()) cannot recognize nested attributes and won't display
      the structure of their contents.
      
      Unfortunately we cannot just add the flag everywhere as there may be
      userspace applications which check nlattr::nla_type directly rather than
      through a helper masking out the flags. Therefore the patch renames
      nla_nest_start() to nla_nest_start_noflag() and introduces nla_nest_start()
      as a wrapper adding NLA_F_NESTED. The calls which add NLA_F_NESTED manually
      are rewritten to use nla_nest_start().
      
      Except for changes in include/net/netlink.h, the patch was generated using
      this semantic patch:
      
      @@ expression E1, E2; @@
      -nla_nest_start(E1, E2)
      +nla_nest_start_noflag(E1, E2)
      
      @@ expression E1, E2; @@
      -nla_nest_start_noflag(E1, E2 | NLA_F_NESTED)
      +nla_nest_start(E1, E2)
      Signed-off-by: NMichal Kubecek <mkubecek@suse.cz>
      Acked-by: NJiri Pirko <jiri@mellanox.com>
      Acked-by: NDavid Ahern <dsahern@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ae0be8de
  28. 21 3月, 2019 1 次提交
  29. 25 2月, 2019 1 次提交
  30. 01 2月, 2019 1 次提交
  31. 18 1月, 2019 2 次提交
  32. 14 12月, 2018 1 次提交
  33. 04 12月, 2018 1 次提交
    • M
      macvlan: return correct error value · 59f997b0
      Matteo Croce 提交于
      A MAC address must be unique among all the macvlan devices with the same
      lower device. The only exception is the passthru [sic] mode,
      which shares the lower device address.
      
      When duplicate addresses are detected, EBUSY is returned when bringing
      the interface up:
      
          # ip link add macvlan0 link eth0 type macvlan
          # read addr </sys/class/net/eth0/address
          # ip link set macvlan0 address $addr
          # ip link set macvlan0 up
          RTNETLINK answers: Device or resource busy
      
      Use correct error code which is EADDRINUSE, and do the check also
      earlier, on address change:
      
          # ip link set macvlan0 address $addr
          RTNETLINK answers: Address already in use
      Signed-off-by: NMatteo Croce <mcroce@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      59f997b0
  34. 20 10月, 2018 1 次提交
    • D
      netpoll: allow cleanup to be synchronous · c9fbd71f
      Debabrata Banerjee 提交于
      This fixes a problem introduced by:
      commit 2cde6acd ("netpoll: Fix __netpoll_rcu_free so that it can hold the rtnl lock")
      
      When using netconsole on a bond, __netpoll_cleanup can asynchronously
      recurse multiple times, each __netpoll_free_async call can result in
      more __netpoll_free_async's. This means there is now a race between
      cleanup_work queues on multiple netpoll_info's on multiple devices and
      the configuration of a new netpoll. For example if a netconsole is set
      to enable 0, reconfigured, and enable 1 immediately, this netconsole
      will likely not work.
      
      Given the reason for __netpoll_free_async is it can be called when rtnl
      is not locked, if it is locked, we should be able to execute
      synchronously. It appears to be locked everywhere it's called from.
      
      Generalize the design pattern from the teaming driver for current
      callers of __netpoll_free_async.
      
      CC: Neil Horman <nhorman@tuxdriver.com>
      CC: "David S. Miller" <davem@davemloft.net>
      Signed-off-by: NDebabrata Banerjee <dbanerje@akamai.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c9fbd71f
  35. 12 7月, 2018 1 次提交
  36. 10 7月, 2018 1 次提交
  37. 25 4月, 2018 2 次提交