1. 24 Feb, 2019 1 commit
  2. 28 Jan, 2019 1 commit
  3. 18 Jan, 2019 3 commits
    • Ido Schimmel's avatar
      net: bridge: Mark FDB entries that were added by user as such · 710ae728
      Ido Schimmel authored
      Externally learned entries can be added by a user or by a switch driver
      that is notifying the bridge driver about entries that were learned in
      hardware.
      
      In the first case, the entries are not marked with the 'added_by_user'
      flag, which causes switch drivers to ignore them and not offload them.
      
      The 'added_by_user' flag can be set on externally learned FDB entries
      based on the 'swdev_notify' parameter in br_fdb_external_learn_add(),
      which effectively means if the created / updated FDB entry was added by
      a user or not.
      
      Fixes: 816a3bed ("switchdev: Add fdb.added_by_user to switchdev notifications")
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Reported-by: default avatarAlexander Petrovskiy <alexpe@mellanox.com>
      Reviewed-by: default avatarPetr Machata <petrm@mellanox.com>
      Cc: Roopa Prabhu <roopa@cumulusnetworks.com>
      Cc: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Cc: bridge@lists.linux-foundation.org
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      710ae728
    • Ross Lagerwall's avatar
      net: Fix usage of pskb_trim_rcsum · 6c57f045
      Ross Lagerwall authored
      In certain cases, pskb_trim_rcsum() may change skb pointers.
      Reinitialize header pointers afterwards to avoid potential
      use-after-frees. Add a note in the documentation of
      pskb_trim_rcsum(). Found by KASAN.
      Signed-off-by: default avatarRoss Lagerwall <ross.lagerwall@citrix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6c57f045
    • Yunjian Wang's avatar
      net: bridge: Fix ethernet header pointer before check skb forwardable · 28c1382f
      Yunjian Wang authored
      The skb header should be set to ethernet header before using
      is_skb_forwardable. Because the ethernet header length has been
      considered in is_skb_forwardable(including dev->hard_header_len
      length).
      
      To reproduce the issue:
      1, add 2 ports on linux bridge br using following commands:
      $ brctl addbr br
      $ brctl addif br eth0
      $ brctl addif br eth1
      2, the MTU of eth0 and eth1 is 1500
      3, send a packet(Data 1480, UDP 8, IP 20, Ethernet 14, VLAN 4)
      from eth0 to eth1
      
      So the expect result is packet larger than 1500 cannot pass through
      eth0 and eth1. But currently, the packet passes through success, it
      means eth1's MTU limit doesn't take effect.
      
      Fixes: f6367b46 ("bridge: use is_skb_forwardable in forward path")
      Cc: bridge@lists.linux-foundation.org
      Cc: Nkolay Aleksandrov <nikolay@cumulusnetworks.com>
      Cc: Roopa Prabhu <roopa@cumulusnetworks.com>
      Cc: Stephen Hemminger <stephen@networkplumber.org>
      Signed-off-by: default avatarYunjian Wang <wangyunjian@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      28c1382f
  4. 12 Jan, 2019 1 commit
  5. 10 Jan, 2019 1 commit
    • Shakeel Butt's avatar
      netfilter: ebtables: account ebt_table_info to kmemcg · e2c8d550
      Shakeel Butt authored
      The [ip,ip6,arp]_tables use x_tables_info internally and the underlying
      memory is already accounted to kmemcg. Do the same for ebtables. The
      syzbot, by using setsockopt(EBT_SO_SET_ENTRIES), was able to OOM the
      whole system from a restricted memcg, a potential DoS.
      
      By accounting the ebt_table_info, the memory used for ebt_table_info can
      be contained within the memcg of the allocating process. However the
      lifetime of ebt_table_info is independent of the allocating process and
      is tied to the network namespace. So, the oom-killer will not be able to
      relieve the memory pressure due to ebt_table_info memory. The memory for
      ebt_table_info is allocated through vmalloc. Currently vmalloc does not
      handle the oom-killed allocating process correctly and one large
      allocation can bypass memcg limit enforcement. So, with this patch,
      at least the small allocations will be contained. For large allocations,
      we need to fix vmalloc.
      
      Reported-by: syzbot+7713f3aa67be76b1552c@syzkaller.appspotmail.com
      Signed-off-by: default avatarShakeel Butt <shakeelb@google.com>
      Reviewed-by: default avatarKirill Tkhai <ktkhai@virtuozzo.com>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      e2c8d550
  6. 08 Jan, 2019 1 commit
    • Ido Schimmel's avatar
      net: bridge: Fix VLANs memory leak · 27973793
      Ido Schimmel authored
      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: default avatarIdo Schimmel <idosch@mellanox.com>
      Reviewed-by: default avatarPetr Machata <petrm@mellanox.com>
      Cc: Roopa Prabhu <roopa@cumulusnetworks.com>
      Cc: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Cc: bridge@lists.linux-foundation.org
      Acked-by: default avatarNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      27973793
  7. 07 Jan, 2019 1 commit
  8. 19 Dec, 2018 2 commits
  9. 18 Dec, 2018 1 commit
  10. 16 Dec, 2018 1 commit
  11. 14 Dec, 2018 2 commits
  12. 13 Dec, 2018 3 commits
  13. 07 Dec, 2018 1 commit
  14. 06 Dec, 2018 4 commits
  15. 01 Dec, 2018 2 commits
  16. 27 Nov, 2018 3 commits
  17. 25 Nov, 2018 1 commit
    • Colin Ian King's avatar
      net: bridge: remove redundant checks for null p->dev and p->br · 40b1c813
      Colin Ian King authored
      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: default avatarColin Ian King <colin.king@canonical.com>
      Acked-by: default avatarNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      40b1c813
  18. 22 Nov, 2018 1 commit
  19. 18 Nov, 2018 1 commit
    • Nikolay Aleksandrov's avatar
      net: bridge: fix vlan stats use-after-free on destruction · 9d332e69
      Nikolay Aleksandrov authored
      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: default avatarNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9d332e69
  20. 09 Nov, 2018 1 commit
  21. 29 Oct, 2018 1 commit
    • Nikolay Aleksandrov's avatar
      net: bridge: remove ipv6 zero address check in mcast queries · 0fe5119e
      Nikolay Aleksandrov authored
      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: default avatarNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0fe5119e
  22. 26 Oct, 2018 1 commit
  23. 20 Oct, 2018 1 commit
    • Debabrata Banerjee's avatar
      netpoll: allow cleanup to be synchronous · c9fbd71f
      Debabrata Banerjee authored
      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: default avatarDebabrata Banerjee <dbanerje@akamai.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c9fbd71f
  24. 18 Oct, 2018 1 commit
  25. 16 Oct, 2018 1 commit
  26. 12 Oct, 2018 1 commit
    • Nikolay Aleksandrov's avatar
      net: bridge: add support for per-port vlan stats · 9163a0fc
      Nikolay Aleksandrov authored
      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: default avatarNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9163a0fc
  27. 08 Oct, 2018 1 commit
  28. 03 Oct, 2018 1 commit