1. 05 Jul, 2017 1 commit
  2. 14 Jun, 2017 2 commits
  3. 22 Mar, 2017 3 commits
  4. 26 Feb, 2017 1 commit
    • Paolo Abeni's avatar
      vxlan: fix oops in dev_fill_metadata_dst · f23fd87e
      Paolo Abeni authored
      [ Upstream commit 22f0708a ]
      Since the commit 0c1d70af ("net: use dst_cache for vxlan device")
      vxlan_fill_metadata_dst() calls vxlan_get_route() passing a NULL
      dst_cache pointer, so the latter should explicitly check for
      valid dst_cache ptr. Unfortunately the commit d71785ff ("net: add
      dst_cache to ovs vxlan lwtunnel") removed said check.
      As a result is possible to trigger a null pointer access calling
      vxlan_fill_metadata_dst(), e.g. with:
      ovs-vsctl add-br ovs-br0
      ovs-vsctl add-port ovs-br0 vxlan0 -- set interface vxlan0 \
      	type=vxlan options:remote_ip= \
      	options:key=1234 options:dst_port=4789 ofport_request=10
      ip address add dev ovs-br0
      ovs-vsctl set Bridge ovs-br0 ipfix=@i -- --id=@i create IPFIX \
      	targets=\"\" sampling=1
      iperf -c -u -l 1000 -b 10M -t 1 -p 1234
      This commit addresses the issue passing to vxlan_get_route() the
      dst_cache already available into the lwt info processed by
      Fixes: d71785ff ("net: add dst_cache to ovs vxlan lwtunnel")
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Acked-by: default avatarJiri Benc <jbenc@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  5. 04 Feb, 2017 1 commit
  6. 30 Nov, 2016 1 commit
  7. 09 Nov, 2016 1 commit
  8. 30 Oct, 2016 1 commit
  9. 20 Oct, 2016 1 commit
    • Sabrina Dubroca's avatar
      net: add recursion limit to GRO · fcd91dd4
      Sabrina Dubroca authored
      Currently, GRO can do unlimited recursion through the gro_receive
      handlers.  This was fixed for tunneling protocols by limiting tunnel GRO
      to one level with encap_mark, but both VLAN and TEB still have this
      problem.  Thus, the kernel is vulnerable to a stack overflow, if we
      receive a packet composed entirely of VLAN headers.
      This patch adds a recursion counter to the GRO layer to prevent stack
      overflow.  When a gro_receive function hits the recursion limit, GRO is
      aborted for this skb and it is processed normally.  This recursion
      counter is put in the GRO CB, but could be turned into a percpu counter
      if we run out of space in the CB.
      Thanks to Vladimír Beneš <vbenes@redhat.com> for the initial bug report.
      Fixes: CVE-2016-7039
      Fixes: 9b174d88 ("net: Add Transparent Ethernet Bridging GRO support.")
      Fixes: 66e5133f ("vlan: Add GRO support for non hardware accelerated vlan")
      Signed-off-by: default avatarSabrina Dubroca <sd@queasysnail.net>
      Reviewed-by: default avatarJiri Benc <jbenc@redhat.com>
      Acked-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Acked-by: default avatarTom Herbert <tom@herbertland.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  10. 11 Sep, 2016 1 commit
  11. 06 Sep, 2016 1 commit
  12. 04 Sep, 2016 3 commits
    • Jiri Benc's avatar
      vxlan: fix duplicated and wrong error messages · 3555621d
      Jiri Benc authored
      vxlan_dev_configure outputs error messages before returning, no need to
      print again the same mesages in vxlan_newlink. Also, vxlan_dev_configure may
      return a particular error code for a different reason than vxlan_newlink
      Move the remaining error messages into vxlan_dev_configure and let
      vxlan_newlink just pass on the error code.
      Signed-off-by: default avatarJiri Benc <jbenc@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Jiri Benc's avatar
      vxlan: reject multicast destination without an interface · 9b4cdd51
      Jiri Benc authored
      Currently, kernel accepts configurations such as:
        ip l a type vxlan dstport 4789 id 1 group
        ip l a type vxlan dstport 4789 id 1 group ff0e::110
      However, neither of those really works. In the IPv4 case, the interface
      cannot be brought up ("RTNETLINK answers: No such device"). This is because
      multicast join will be rejected without the interface being specified.
      In the IPv6 case, multicast wil be joined on the first interface found. This
      is not what the user wants as it depends on random factors (order of
      Note that it's possible to add a local address but it doesn't solve
      anything. For IPv4, it's not considered in the multicast join (thus the same
      error as above is returned on ifup). This could be added but it wouldn't
      help for IPv6 anyway. For IPv6, we do need the interface.
      Just reject a configuration that sets multicast address and does not provide
      an interface. Nobody can depend on the previous behavior as it never worked.
      Signed-off-by: default avatarJiri Benc <jbenc@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • WANG Cong's avatar
      vxlan: call peernet2id() in fdb notification · 38f507f1
      WANG Cong authored
      netns id should be already allocated each time we change
      netns, that is, in dev_change_net_namespace() (more precisely
      in rtnl_fill_ifinfo()). It is safe to just call peernet2id() here.
      Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Acked-by: default avatarNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  13. 01 Sep, 2016 1 commit
    • Roopa Prabhu's avatar
      rtnetlink: fdb dump: optimize by saving last interface markers · d297653d
      Roopa Prabhu authored
      fdb dumps spanning multiple skb's currently restart from the first
      interface again for every skb. This results in unnecessary
      iterations on the already visited interfaces and their fdb
      entries. In large scale setups, we have seen this to slow
      down fdb dumps considerably. On a system with 30k macs we
      see fdb dumps spanning across more than 300 skbs.
      To fix the problem, this patch replaces the existing single fdb
      marker with three markers: netdev hash entries, netdevs and fdb
      index to continue where we left off instead of restarting from the
      first netdev. This is consistent with link dumps.
      In the process of fixing the performance issue, this patch also
      re-implements fix done by
      commit 472681d5 ("net: ndo_fdb_dump should report -EMSGSIZE to rtnl_fdb_dump")
      (with an internal fix from Wilson Kok) in the following ways:
      - change ndo_fdb_dump handlers to return error code instead
      of the last fdb index
      - use cb->args strictly for dump frag markers and not error codes.
      This is consistent with other dump functions.
      Below results were taken on a system with 1000 netdevs
      and 35085 fdb entries:
      before patch:
      $time bridge fdb show | wc -l
      real    1m11.791s
      user    0m0.070s
      sys 1m8.395s
      (existing code does not return all macs)
      after patch:
      $time bridge fdb show | wc -l
      real    0m2.017s
      user    0m0.113s
      sys 0m1.942s
      Signed-off-by: default avatarRoopa Prabhu <roopa@cumulusnetworks.com>
      Signed-off-by: default avatarWilson Kok <wkok@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  14. 27 Aug, 2016 1 commit
  15. 08 Aug, 2016 2 commits
  16. 11 Jul, 2016 1 commit
  17. 18 Jun, 2016 4 commits
  18. 15 Jun, 2016 1 commit
    • Nicolas Dichtel's avatar
      ovs/vxlan: fix rtnl notifications on iface deletion · cf5da330
      Nicolas Dichtel authored
      The function vxlan_dev_create() (only used by ovs) never calls
      rtnl_configure_link(). The consequence is that dev->rtnl_link_state is
      never set to RTNL_LINK_INITIALIZED.
      During the deletion phase, the function rollback_registered_many() sends
      a RTM_DELLINK only if dev->rtnl_link_state is set to RTNL_LINK_INITIALIZED.
      Note that the function vxlan_dev_create() is moved after the rtnl stuff so
      that vxlan_dellink() can be called in this function.
      Fixes: dcc38c03 ("openvswitch: Re-add CONFIG_OPENVSWITCH_VXLAN")
      CC: Thomas Graf <tgraf@suug.ch>
      CC: Pravin B Shelar <pshelar@nicira.com>
      Signed-off-by: default avatarNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  19. 31 May, 2016 1 commit
  20. 20 May, 2016 1 commit
  21. 16 May, 2016 1 commit
  22. 06 May, 2016 2 commits
  23. 29 Apr, 2016 1 commit
  24. 21 Apr, 2016 1 commit
    • Hannes Frederic Sowa's avatar
      vxlan: break dependency with netdev drivers · b7aade15
      Hannes Frederic Sowa authored
      Currently all drivers depend and autoload the vxlan module because how
      vxlan_get_rx_port is linked into them. Remove this dependency:
      By using a new event type in the netdevice notifier call chain we proxy
      the request from the drivers to flush and resetup the vxlan ports not
      directly via function call but by the already existing netdevice
      notifier call chain.
      I added a separate new event type, NETDEV_OFFLOAD_PUSH_VXLAN, to do so.
      We don't need to save those ids, as the event type field is an unsigned
      long and using specialized event types for this purpose seemed to be a
      more elegant way. This also comes in beneficial if in future we want to
      add offloading knobs for vxlan.
      Cc: Jesse Gross <jesse@kernel.org>
      Signed-off-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  25. 16 Apr, 2016 3 commits
  26. 11 Apr, 2016 1 commit
  27. 07 Apr, 2016 1 commit
  28. 06 Apr, 2016 1 commit
    • Jiri Benc's avatar
      vxlan: implement GPE · e1e5314d
      Jiri Benc authored
      Implement VXLAN-GPE. Only COLLECT_METADATA is supported for now (it is
      possible to support static configuration, too, if there is demand for it).
      The GPE header parsing has to be moved before iptunnel_pull_header, as we
      need to know the protocol.
      v2: Removed what was called "L2 mode" in v1 of the patchset. Only "L3 mode"
          (now called "raw mode") is added by this patch. This mode does not allow
          Ethernet header to be encapsulated in VXLAN-GPE when using ip route to
          specify the encapsulation, IP header is encapsulated instead. The patch
          does support Ethernet to be encapsulated, though, using ETH_P_TEB in
          skb->protocol. This will be utilized by other COLLECT_METADATA users
          (openvswitch in particular).
          If there is ever demand for Ethernet encapsulation with VXLAN-GPE using
          ip route, it's easy to add a new flag switching the interface to
          "Ethernet mode" (called "L2 mode" in v1 of this patchset). For now,
          leave this out, it seems we don't need it.
          Disallowed more flag combinations, especially RCO with GPE.
          Added comment explaining that GBP and GPE cannot be set together.
      Signed-off-by: default avatarJiri Benc <jbenc@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>