1. 30 6月, 2021 1 次提交
  2. 29 6月, 2021 5 次提交
  3. 23 6月, 2021 1 次提交
  4. 19 6月, 2021 1 次提交
  5. 11 6月, 2021 2 次提交
    • N
      net: bridge: fix vlan tunnel dst refcnt when egressing · cfc579f9
      Nikolay Aleksandrov 提交于
      The egress tunnel code uses dst_clone() and directly sets the result
      which is wrong because the entry might have 0 refcnt or be already deleted,
      causing number of problems. It also triggers the WARN_ON() in dst_hold()[1]
      when a refcnt couldn't be taken. Fix it by using dst_hold_safe() and
      checking if a reference was actually taken before setting the dst.
      
      [1] dmesg WARN_ON log and following refcnt errors
       WARNING: CPU: 5 PID: 38 at include/net/dst.h:230 br_handle_egress_vlan_tunnel+0x10b/0x134 [bridge]
       Modules linked in: 8021q garp mrp bridge stp llc bonding ipv6 virtio_net
       CPU: 5 PID: 38 Comm: ksoftirqd/5 Kdump: loaded Tainted: G        W         5.13.0-rc3+ #360
       Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014
       RIP: 0010:br_handle_egress_vlan_tunnel+0x10b/0x134 [bridge]
       Code: e8 85 bc 01 e1 45 84 f6 74 90 45 31 f6 85 db 48 c7 c7 a0 02 19 a0 41 0f 94 c6 31 c9 31 d2 44 89 f6 e8 64 bc 01 e1 85 db 75 02 <0f> 0b 31 c9 31 d2 44 89 f6 48 c7 c7 70 02 19 a0 e8 4b bc 01 e1 49
       RSP: 0018:ffff8881003d39e8 EFLAGS: 00010246
       RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
       RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffffffa01902a0
       RBP: ffff8881040c6700 R08: 0000000000000000 R09: 0000000000000001
       R10: 2ce93d0054fe0d00 R11: 54fe0d00000e0000 R12: ffff888109515000
       R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000401
       FS:  0000000000000000(0000) GS:ffff88822bf40000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 00007f42ba70f030 CR3: 0000000109926000 CR4: 00000000000006e0
       Call Trace:
        br_handle_vlan+0xbc/0xca [bridge]
        __br_forward+0x23/0x164 [bridge]
        deliver_clone+0x41/0x48 [bridge]
        br_handle_frame_finish+0x36f/0x3aa [bridge]
        ? skb_dst+0x2e/0x38 [bridge]
        ? br_handle_ingress_vlan_tunnel+0x3e/0x1c8 [bridge]
        ? br_handle_frame_finish+0x3aa/0x3aa [bridge]
        br_handle_frame+0x2c3/0x377 [bridge]
        ? __skb_pull+0x33/0x51
        ? vlan_do_receive+0x4f/0x36a
        ? br_handle_frame_finish+0x3aa/0x3aa [bridge]
        __netif_receive_skb_core+0x539/0x7c6
        ? __list_del_entry_valid+0x16e/0x1c2
        __netif_receive_skb_list_core+0x6d/0xd6
        netif_receive_skb_list_internal+0x1d9/0x1fa
        gro_normal_list+0x22/0x3e
        dev_gro_receive+0x55b/0x600
        ? detach_buf_split+0x58/0x140
        napi_gro_receive+0x94/0x12e
        virtnet_poll+0x15d/0x315 [virtio_net]
        __napi_poll+0x2c/0x1c9
        net_rx_action+0xe6/0x1fb
        __do_softirq+0x115/0x2d8
        run_ksoftirqd+0x18/0x20
        smpboot_thread_fn+0x183/0x19c
        ? smpboot_unregister_percpu_thread+0x66/0x66
        kthread+0x10a/0x10f
        ? kthread_mod_delayed_work+0xb6/0xb6
        ret_from_fork+0x22/0x30
       ---[ end trace 49f61b07f775fd2b ]---
       dst_release: dst:00000000c02d677a refcnt:-1
       dst_release underflow
      
      Cc: stable@vger.kernel.org
      Fixes: 11538d03 ("bridge: vlan dst_metadata hooks in ingress and egress paths")
      Signed-off-by: NNikolay Aleksandrov <nikolay@nvidia.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cfc579f9
    • N
      net: bridge: fix vlan tunnel dst null pointer dereference · 58e20717
      Nikolay Aleksandrov 提交于
      This patch fixes a tunnel_dst null pointer dereference due to lockless
      access in the tunnel egress path. When deleting a vlan tunnel the
      tunnel_dst pointer is set to NULL without waiting a grace period (i.e.
      while it's still usable) and packets egressing are dereferencing it
      without checking. Use READ/WRITE_ONCE to annotate the lockless use of
      tunnel_id, use RCU for accessing tunnel_dst and make sure it is read
      only once and checked in the egress path. The dst is already properly RCU
      protected so we don't need to do anything fancy than to make sure
      tunnel_id and tunnel_dst are read only once and checked in the egress path.
      
      Cc: stable@vger.kernel.org
      Fixes: 11538d03 ("bridge: vlan dst_metadata hooks in ingress and egress paths")
      Signed-off-by: NNikolay Aleksandrov <nikolay@nvidia.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      58e20717
  6. 05 6月, 2021 1 次提交
  7. 26 5月, 2021 1 次提交
  8. 15 5月, 2021 2 次提交
    • M
      net: bridge: fix build when IPv6 is disabled · 30515832
      Matteo Croce 提交于
      The br_ip6_multicast_add_router() prototype is defined only when
      CONFIG_IPV6 is enabled, but the function is always referenced, so there
      is this build error with CONFIG_IPV6 not defined:
      
      net/bridge/br_multicast.c: In function ‘__br_multicast_enable_port’:
      net/bridge/br_multicast.c:1743:3: error: implicit declaration of function ‘br_ip6_multicast_add_router’; did you mean ‘br_ip4_multicast_add_router’? [-Werror=implicit-function-declaration]
       1743 |   br_ip6_multicast_add_router(br, port);
            |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~
            |   br_ip4_multicast_add_router
      net/bridge/br_multicast.c: At top level:
      net/bridge/br_multicast.c:2804:13: warning: conflicting types for ‘br_ip6_multicast_add_router’
       2804 | static void br_ip6_multicast_add_router(struct net_bridge *br,
            |             ^~~~~~~~~~~~~~~~~~~~~~~~~~~
      net/bridge/br_multicast.c:2804:13: error: static declaration of ‘br_ip6_multicast_add_router’ follows non-static declaration
      net/bridge/br_multicast.c:1743:3: note: previous implicit declaration of ‘br_ip6_multicast_add_router’ was here
       1743 |   br_ip6_multicast_add_router(br, port);
            |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      Fix this build error by moving the definition out of the #ifdef.
      
      Fixes: a3c02e76 ("net: bridge: mcast: split multicast router state for IPv4 and IPv6")
      Signed-off-by: NMatteo Croce <mcroce@microsoft.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      30515832
    • N
      net: bridge: fix br_multicast_is_router stub when igmp is disabled · bbc6f2cc
      Nikolay Aleksandrov 提交于
      br_multicast_is_router takes two arguments when bridge IGMP is enabled
      and just one when it's disabled, fix the stub to take two as well.
      
      Fixes: 1a3065a2 ("net: bridge: mcast: prepare is-router function for mcast router split")
      Signed-off-by: NNikolay Aleksandrov <nikolay@nvidia.com>
      Acked-by: NLinus Lüssing <linus.luessing@c0d3.blue>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bbc6f2cc
  9. 14 5月, 2021 11 次提交
  10. 30 4月, 2021 1 次提交
    • Z
      bridge: Fix possible races between assigning rx_handler_data and setting IFF_BRIDGE_PORT bit · 59259ff7
      Zhang Zhengming 提交于
      There is a crash in the function br_get_link_af_size_filtered,
      as the port_exists(dev) is true and the rx_handler_data of dev is NULL.
      But the rx_handler_data of dev is correct saved in vmcore.
      
      The oops looks something like:
       ...
       pc : br_get_link_af_size_filtered+0x28/0x1c8 [bridge]
       ...
       Call trace:
        br_get_link_af_size_filtered+0x28/0x1c8 [bridge]
        if_nlmsg_size+0x180/0x1b0
        rtnl_calcit.isra.12+0xf8/0x148
        rtnetlink_rcv_msg+0x334/0x370
        netlink_rcv_skb+0x64/0x130
        rtnetlink_rcv+0x28/0x38
        netlink_unicast+0x1f0/0x250
        netlink_sendmsg+0x310/0x378
        sock_sendmsg+0x4c/0x70
        __sys_sendto+0x120/0x150
        __arm64_sys_sendto+0x30/0x40
        el0_svc_common+0x78/0x130
        el0_svc_handler+0x38/0x78
        el0_svc+0x8/0xc
      
      In br_add_if(), we found there is no guarantee that
      assigning rx_handler_data to dev->rx_handler_data
      will before setting the IFF_BRIDGE_PORT bit of priv_flags.
      So there is a possible data competition:
      
      CPU 0:                                                        CPU 1:
      (RCU read lock)                                               (RTNL lock)
      rtnl_calcit()                                                 br_add_slave()
        if_nlmsg_size()                                               br_add_if()
          br_get_link_af_size_filtered()                              -> netdev_rx_handler_register
                                                                          ...
                                                                          // The order is not guaranteed
            ...                                                           -> dev->priv_flags |= IFF_BRIDGE_PORT;
            // The IFF_BRIDGE_PORT bit of priv_flags has been set
            -> if (br_port_exists(dev)) {
              // The dev->rx_handler_data has NOT been assigned
              -> p = br_port_get_rcu(dev);
              ....
                                                                          -> rcu_assign_pointer(dev->rx_handler_data, rx_handler_data);
                                                                           ...
      
      Fix it in br_get_link_af_size_filtered, using br_port_get_check_rcu() and checking the return value.
      Signed-off-by: NZhang Zhengming <zhangzhengming@huawei.com>
      Reviewed-by: NZhao Lei <zhaolei69@huawei.com>
      Reviewed-by: NWang Xiaogang <wangxiaogang3@huawei.com>
      Suggested-by: NNikolay Aleksandrov <nikolay@nvidia.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      59259ff7
  11. 28 4月, 2021 1 次提交
    • L
      net: bridge: mcast: fix broken length + header check for MRDv6 Adv. · 99014088
      Linus Lüssing 提交于
      The IPv6 Multicast Router Advertisements parsing has the following two
      issues:
      
      For one thing, ICMPv6 MRD Advertisements are smaller than ICMPv6 MLD
      messages (ICMPv6 MRD Adv.: 8 bytes vs. ICMPv6 MLDv1/2: >= 24 bytes,
      assuming MLDv2 Reports with at least one multicast address entry).
      When ipv6_mc_check_mld_msg() tries to parse an Multicast Router
      Advertisement its MLD length check will fail - and it will wrongly
      return -EINVAL, even if we have a valid MRD Advertisement. With the
      returned -EINVAL the bridge code will assume a broken packet and will
      wrongly discard it, potentially leading to multicast packet loss towards
      multicast routers.
      
      The second issue is the MRD header parsing in
      br_ip6_multicast_mrd_rcv(): It wrongly checks for an ICMPv6 header
      immediately after the IPv6 header (IPv6 next header type). However
      according to RFC4286, section 2 all MRD messages contain a Router Alert
      option (just like MLD). So instead there is an IPv6 Hop-by-Hop option
      for the Router Alert between the IPv6 and ICMPv6 header, again leading
      to the bridge wrongly discarding Multicast Router Advertisements.
      
      To fix these two issues, introduce a new return value -ENODATA to
      ipv6_mc_check_mld() to indicate a valid ICMPv6 packet with a hop-by-hop
      option which is not an MLD but potentially an MRD packet. This also
      simplifies further parsing in the bridge code, as ipv6_mc_check_mld()
      already fully checks the ICMPv6 header and hop-by-hop option.
      
      These issues were found and fixed with the help of the mrdisc tool
      (https://github.com/troglobit/mrdisc).
      
      Fixes: 4b3087c7 ("bridge: Snoop Multicast Router Advertisements")
      Signed-off-by: NLinus Lüssing <linus.luessing@c0d3.blue>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      99014088
  12. 27 4月, 2021 1 次提交
  13. 26 4月, 2021 1 次提交
    • F
      netfilter: ebtables: remove the 3 ebtables pointers from struct net · 4c95e072
      Florian Westphal 提交于
      ebtables stores the table internal data (what gets passed to the
      ebt_do_table() interpreter) in struct net.
      
      nftables keeps the internal interpreter format in pernet lists
      and passes it via the netfilter core infrastructure (priv pointer).
      
      Do the same for ebtables: the nf_hook_ops are duplicated via kmemdup,
      then the ops->priv pointer is set to the table that is being registered.
      
      After that, the netfilter core passes this table info to the hookfn.
      
      This allows to remove the pointers from struct net.
      
      Same pattern can be applied to ip/ip6/arptables.
      Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      4c95e072
  14. 22 4月, 2021 1 次提交
  15. 17 4月, 2021 2 次提交
  16. 15 4月, 2021 1 次提交
  17. 11 4月, 2021 1 次提交
    • F
      netfilter: bridge: add pre_exit hooks for ebtable unregistration · 7ee3c61d
      Florian Westphal 提交于
      Just like ip/ip6/arptables, the hooks have to be removed, then
      synchronize_rcu() has to be called to make sure no more packets are being
      processed before the ruleset data is released.
      
      Place the hook unregistration in the pre_exit hook, then call the new
      ebtables pre_exit function from there.
      
      Years ago, when first netns support got added for netfilter+ebtables,
      this used an older (now removed) netfilter hook unregister API, that did
      a unconditional synchronize_rcu().
      
      Now that all is done with call_rcu, ebtable_{filter,nat,broute} pernet exit
      handlers may free the ebtable ruleset while packets are still in flight.
      
      This can only happens on module removal, not during netns exit.
      
      The new function expects the table name, not the table struct.
      
      This is because upcoming patch set (targeting -next) will remove all
      net->xt.{nat,filter,broute}_table instances, this makes it necessary
      to avoid external references to those member variables.
      
      The existing APIs will be converted, so follow the upcoming scheme of
      passing name + hook type instead.
      
      Fixes: aee12a0a ("ebtables: remove nf_hook_register usage")
      Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      7ee3c61d
  18. 06 4月, 2021 1 次提交
  19. 01 4月, 2021 1 次提交
  20. 25 3月, 2021 4 次提交