1. 09 1月, 2019 1 次提交
    • I
      net: bridge: Fix VLANs memory leak · 27973793
      Ido Schimmel 提交于
      When adding / deleting VLANs to / from a bridge port, the bridge driver
      first tries to propagate the information via switchdev and falls back to
      the 8021q driver in case the underlying driver does not support
      switchdev. This can result in a memory leak [1] when VXLAN and mlxsw
      ports are enslaved to the bridge:
      
      $ ip link set dev vxlan0 master br0
      # No mlxsw ports are enslaved to 'br0', so mlxsw ignores the switchdev
      # notification and the bridge driver adds the VLAN on 'vxlan0' via the
      # 8021q driver
      $ bridge vlan add vid 10 dev vxlan0 pvid untagged
      # mlxsw port is enslaved to the bridge
      $ ip link set dev swp1 master br0
      # mlxsw processes the switchdev notification and the 8021q driver is
      # skipped
      $ bridge vlan del vid 10 dev vxlan0
      
      This results in 'struct vlan_info' and 'struct vlan_vid_info' being
      leaked, as they were allocated by the 8021q driver during VLAN addition,
      but never freed as the 8021q driver was skipped during deletion.
      
      Fix this by introducing a new VLAN private flag that indicates whether
      the VLAN was added on the port by switchdev or the 8021q driver. If the
      VLAN was added by the 8021q driver, then we make sure to delete it via
      the 8021q driver as well.
      
      [1]
      unreferenced object 0xffff88822d20b1e8 (size 256):
        comm "bridge", pid 2532, jiffies 4295216998 (age 1188.830s)
        hex dump (first 32 bytes):
          e0 42 97 ce 81 88 ff ff 00 00 00 00 00 00 00 00  .B..............
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        backtrace:
          [<00000000f82d851d>] kmem_cache_alloc_trace+0x1be/0x330
          [<00000000e0178b02>] vlan_vid_add+0x661/0x920
          [<00000000218ebd5f>] __vlan_add+0x1be9/0x3a00
          [<000000006eafa1ca>] nbp_vlan_add+0x8b3/0xd90
          [<000000003535392c>] br_vlan_info+0x132/0x410
          [<00000000aedaa9dc>] br_afspec+0x75c/0x870
          [<00000000f5716133>] br_setlink+0x3dc/0x6d0
          [<00000000aceca5e2>] rtnl_bridge_setlink+0x615/0xb30
          [<00000000a2f2d23e>] rtnetlink_rcv_msg+0x3a3/0xa80
          [<0000000064097e69>] netlink_rcv_skb+0x152/0x3c0
          [<000000008be8d614>] rtnetlink_rcv+0x21/0x30
          [<000000009ab2ca25>] netlink_unicast+0x52f/0x740
          [<00000000e7d9ac96>] netlink_sendmsg+0x9c7/0xf50
          [<000000005d1e2050>] sock_sendmsg+0xbe/0x120
          [<00000000d51426bc>] ___sys_sendmsg+0x778/0x8f0
          [<00000000b9d7b2cc>] __sys_sendmsg+0x112/0x270
      unreferenced object 0xffff888227454308 (size 32):
        comm "bridge", pid 2532, jiffies 4295216998 (age 1188.882s)
        hex dump (first 32 bytes):
          88 b2 20 2d 82 88 ff ff 88 b2 20 2d 82 88 ff ff  .. -...... -....
          81 00 0a 00 01 00 00 00 00 00 00 00 00 00 00 00  ................
        backtrace:
          [<00000000f82d851d>] kmem_cache_alloc_trace+0x1be/0x330
          [<0000000018050631>] vlan_vid_add+0x3e6/0x920
          [<00000000218ebd5f>] __vlan_add+0x1be9/0x3a00
          [<000000006eafa1ca>] nbp_vlan_add+0x8b3/0xd90
          [<000000003535392c>] br_vlan_info+0x132/0x410
          [<00000000aedaa9dc>] br_afspec+0x75c/0x870
          [<00000000f5716133>] br_setlink+0x3dc/0x6d0
          [<00000000aceca5e2>] rtnl_bridge_setlink+0x615/0xb30
          [<00000000a2f2d23e>] rtnetlink_rcv_msg+0x3a3/0xa80
          [<0000000064097e69>] netlink_rcv_skb+0x152/0x3c0
          [<000000008be8d614>] rtnetlink_rcv+0x21/0x30
          [<000000009ab2ca25>] netlink_unicast+0x52f/0x740
          [<00000000e7d9ac96>] netlink_sendmsg+0x9c7/0xf50
          [<000000005d1e2050>] sock_sendmsg+0xbe/0x120
          [<00000000d51426bc>] ___sys_sendmsg+0x778/0x8f0
          [<00000000b9d7b2cc>] __sys_sendmsg+0x112/0x270
      
      Fixes: d70e42b2 ("mlxsw: spectrum: Enable VxLAN enslavement to VLAN-aware bridges")
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Reviewed-by: NPetr Machata <petrm@mellanox.com>
      Cc: Roopa Prabhu <roopa@cumulusnetworks.com>
      Cc: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Cc: bridge@lists.linux-foundation.org
      Acked-by: NNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      27973793
  2. 08 1月, 2019 1 次提交
  3. 20 12月, 2018 2 次提交
  4. 19 12月, 2018 1 次提交
  5. 17 12月, 2018 1 次提交
  6. 14 12月, 2018 2 次提交
  7. 13 12月, 2018 3 次提交
  8. 08 12月, 2018 1 次提交
  9. 06 12月, 2018 4 次提交
  10. 02 12月, 2018 1 次提交
  11. 01 12月, 2018 1 次提交
  12. 28 11月, 2018 3 次提交
  13. 26 11月, 2018 1 次提交
    • C
      net: bridge: remove redundant checks for null p->dev and p->br · 40b1c813
      Colin Ian King 提交于
      A recent change added a null check on p->dev after p->dev was being
      dereferenced by the ns_capable check on p->dev. It turns out that
      neither the p->dev and p->br null checks are necessary, and can be
      removed, which cleans up a static analyis warning.
      
      As Nikolay Aleksandrov noted, these checks can be removed because:
      
      "My reasoning of why it shouldn't be possible:
      - On port add new_nbp() sets both p->dev and p->br before creating
        kobj/sysfs
      
      - On port del (trickier) del_nbp() calls kobject_del() before call_rcu()
        to destroy the port which in turn calls sysfs_remove_dir() which uses
        kernfs_remove() which deactivates (shouldn't be able to open new
        files) and calls kernfs_drain() to drain current open/mmaped files in
        the respective dir before continuing, thus making it impossible to
        open a bridge port sysfs file with p->dev and p->br equal to NULL.
      
      So I think it's safe to remove those checks altogether. It'd be nice to
      get a second look over my reasoning as I might be missing something in
      sysfs/kernfs call path."
      
      Thanks to Nikolay Aleksandrov's suggestion to remove the check and
      David Miller for sanity checking this.
      
      Detected by CoverityScan, CID#751490 ("Dereference before null check")
      
      Fixes: a5f3ea54 ("net: bridge: add support for raw sysfs port options")
      Signed-off-by: NColin Ian King <colin.king@canonical.com>
      Acked-by: NNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      40b1c813
  14. 22 11月, 2018 1 次提交
  15. 18 11月, 2018 1 次提交
    • N
      net: bridge: fix vlan stats use-after-free on destruction · 9d332e69
      Nikolay Aleksandrov 提交于
      Syzbot reported a use-after-free of the global vlan context on port vlan
      destruction. When I added per-port vlan stats I missed the fact that the
      global vlan context can be freed before the per-port vlan rcu callback.
      There're a few different ways to deal with this, I've chosen to add a
      new private flag that is set only when per-port stats are allocated so
      we can directly check it on destruction without dereferencing the global
      context at all. The new field in net_bridge_vlan uses a hole.
      
      v2: cosmetic change, move the check to br_process_vlan_info where the
          other checks are done
      v3: add change log in the patch, add private (in-kernel only) flags in a
          hole in net_bridge_vlan struct and use that instead of mixing
          user-space flags with private flags
      
      Fixes: 9163a0fc ("net: bridge: add support for per-port vlan stats")
      Reported-by: syzbot+04681da557a0e49a52e5@syzkaller.appspotmail.com
      Signed-off-by: NNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9d332e69
  16. 09 11月, 2018 1 次提交
  17. 29 10月, 2018 1 次提交
    • N
      net: bridge: remove ipv6 zero address check in mcast queries · 0fe5119e
      Nikolay Aleksandrov 提交于
      Recently a check was added which prevents marking of routers with zero
      source address, but for IPv6 that cannot happen as the relevant RFCs
      actually forbid such packets:
      RFC 2710 (MLDv1):
      "To be valid, the Query message MUST
       come from a link-local IPv6 Source Address, be at least 24 octets
       long, and have a correct MLD checksum."
      
      Same goes for RFC 3810.
      
      And also it can be seen as a requirement in ipv6_mc_check_mld_query()
      which is used by the bridge to validate the message before processing
      it. Thus any queries with :: source address won't be processed anyway.
      So just remove the check for zero IPv6 source address from the query
      processing function.
      
      Fixes: 5a2de63f ("bridge: do not add port to router list when receives query with source 0.0.0.0")
      Signed-off-by: NNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0fe5119e
  18. 27 10月, 2018 1 次提交
  19. 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
  20. 18 10月, 2018 1 次提交
  21. 16 10月, 2018 1 次提交
  22. 13 10月, 2018 1 次提交
    • N
      net: bridge: add support for per-port vlan stats · 9163a0fc
      Nikolay Aleksandrov 提交于
      This patch adds an option to have per-port vlan stats instead of the
      default global stats. The option can be set only when there are no port
      vlans in the bridge since we need to allocate the stats if it is set
      when vlans are being added to ports (and respectively free them
      when being deleted). Also bump RTNL_MAX_TYPE as the bridge is the
      largest user of options. The current stats design allows us to add
      these without any changes to the fast-path, it all comes down to
      the per-vlan stats pointer which, if this option is enabled, will
      be allocated for each port vlan instead of using the global bridge-wide
      one.
      
      CC: bridge@lists.linux-foundation.org
      CC: Roopa Prabhu <roopa@cumulusnetworks.com>
      Signed-off-by: NNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9163a0fc
  23. 09 10月, 2018 1 次提交
  24. 03 10月, 2018 1 次提交
  25. 29 9月, 2018 1 次提交
  26. 27 9月, 2018 6 次提交