linux/drivers/net/vxlan.c, branch v4.9

vxlan: fix a potential issue when create a new vxlan fdb entry.

2016-11-30T17:02:49Z

vxlan_fdb_append may return error, so add the proper check, otherwise it will cause memory leak. Signed-off-by: Haishuang Yan Changes in v2: - Unnecessary to initialize rc to zero. Acked-by: Jiri Benc Signed-off-by: David S. Miller

vxlan: hide unused local variable

2016-11-09T23:59:50Z

A bugfix introduced a harmless warning in v4.9-rc4: drivers/net/vxlan.c: In function 'vxlan_group_used': drivers/net/vxlan.c:947:21: error: unused variable 'sock6' [-Werror=unused-variable] This hides the variable inside of the same #ifdef that is around its user. The extraneous initialization is removed at the same time, it was accidentally introduced in the same commit. Fixes: c6fcc4fc5f8b ("vxlan: avoid using stale vxlan socket.") Signed-off-by: Arnd Bergmann Acked-by: Jiri Benc Signed-off-by: David S. Miller

vxlan: avoid using stale vxlan socket.

2016-10-30T00:56:31Z

When vxlan device is closed vxlan socket is freed. This operation can race with vxlan-xmit function which dereferences vxlan socket. Following patch uses RCU mechanism to avoid this situation. Signed-off-by: Pravin B Shelar Signed-off-by: David S. Miller

net: add recursion limit to GRO

2016-10-20T18:32:22Z

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š for the initial bug report. Fixes: CVE-2016-7039 Fixes: 9b174d88c257 ("net: Add Transparent Ethernet Bridging GRO support.") Fixes: 66e5133f19e9 ("vlan: Add GRO support for non hardware accelerated vlan") Signed-off-by: Sabrina Dubroca Reviewed-by: Jiri Benc Acked-by: Hannes Frederic Sowa Acked-by: Tom Herbert Signed-off-by: David S. Miller

Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net

2016-09-12T22:52:44Z

Conflicts: drivers/net/ethernet/mediatek/mtk_eth_soc.c drivers/net/ethernet/qlogic/qed/qed_dcbx.c drivers/net/phy/Kconfig All conflicts were cases of overlapping commits. Signed-off-by: David S. Miller

net/ip_tunnels: Introduce tunnel_id_to_key32() and key32_to_tunnel_id()

2016-09-11T03:53:55Z

Add utility functions to convert a 32 bits key into a 64 bits tunnel and vice versa. These functions will be used instead of cloning code in GRE and VXLAN, and in tc act_iptunnel which will be introduced in a following patch in this patchset. Signed-off-by: Amir Vadai Signed-off-by: Hadar Hen Zion Reviewed-by: Shmulik Ladkani Acked-by: Jiri Benc Acked-by: Jiri Pirko Signed-off-by: David S. Miller

vxlan: Update tx_errors statistics if vxlan_build_skb return err.

2016-09-06T20:41:42Z

If vxlan_build_skb return err < 0, tx_errors should be also increased. Signed-off-by: Haishuang Yan Acked-by: Jiri Benc Signed-off-by: David S. Miller

vxlan: fix duplicated and wrong error messages

2016-09-04T18:42:56Z

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 thinks. Move the remaining error messages into vxlan_dev_configure and let vxlan_newlink just pass on the error code. Signed-off-by: Jiri Benc Signed-off-by: David S. Miller

vxlan: reject multicast destination without an interface

2016-09-04T18:42:56Z

Currently, kernel accepts configurations such as: ip l a type vxlan dstport 4789 id 1 group 239.192.0.1 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 interfaces). 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: Jiri Benc Signed-off-by: David S. Miller

vxlan: call peernet2id() in fdb notification

2016-09-04T18:39:58Z

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 Signed-off-by: Cong Wang Acked-by: Nicolas Dichtel Signed-off-by: David S. Miller