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

vxlan: fix missing options_len update on RX with collect metadata

2016-03-03T22:10:31Z

When signalling to metadata consumers that the metadata_dst entry carries additional GBP extension data for vxlan (TUNNEL_VXLAN_OPT), the dst's vxlan_metadata information is populated, but options_len is left to zero. F.e. in ovs, ovs_flow_key_extract() checks for options_len before extracting the data through ip_tunnel_info_opts_get(). Geneve uses ip_tunnel_info_opts_set() helper in receive path, which sets options_len internally, vxlan however uses ip_tunnel_info_opts(), so when filling vxlan_metadata, we do need to update options_len. Fixes: 4c22279848c5 ("ip-tunnel: Use API to access tunnel metadata options.") Signed-off-by: Daniel Borkmann Acked-by: Thomas Graf Signed-off-by: David S. Miller

net: ndo_fdb_dump should report -EMSGSIZE to rtnl_fdb_dump.

2016-02-26T20:04:02Z

When the send skbuff reaches the end, nlmsg_put and friends returns -EMSGSIZE but it is silently thrown away in ndo_fdb_dump. It is called within a for_each_netdev loop and the first fdb entry of a following netdev could fit in the remaining skbuff. This breaks the mechanism of cb->args[0] and idx to keep track of the entries that are already dumped, which results missing entries in bridge fdb show command. Signed-off-by: Minoura Makoto Signed-off-by: David S. Miller

vxlan: do not use fdb in metadata mode

2016-02-18T20:01:14Z

In metadata mode, the vxlan interface is not supposed to use the fdb control plane but an external one (openvswitch or static routes). With the current code, packets may leak into the fdb handling code which usually causes them to be dropped anyway but may have strange side effects. Just drop the packets directly when in metadata mode if the destination data are not correctly provided on egress. Signed-off-by: Jiri Benc Signed-off-by: David S. Miller

vxlan: clear IFF_TX_SKB_SHARING

2016-02-18T19:43:47Z

ether_setup sets IFF_TX_SKB_SHARING but this is not supported by vxlan as it modifies the skb on xmit. Signed-off-by: Jiri Benc Signed-off-by: David S. Miller

vxlan, gre, geneve: Set a large MTU on ovs-created tunnel devices

2016-02-10T10:50:03Z

Prior to 4.3, openvswitch tunnel vports (vxlan, gre and geneve) could transmit vxlan packets of any size, constrained only by the ability to send out the resulting packets. 4.3 introduced netdevs corresponding to tunnel vports. These netdevs have an MTU, which limits the size of a packet that can be successfully encapsulated. The default MTU values are low (1500 or less), which is awkwardly small in the context of physical networks supporting jumbo frames, and leads to a conspicuous change in behaviour for userspace. Instead, set the MTU on openvswitch-created netdevs to be the relevant maximum (i.e. the maximum IP packet size minus any relevant overhead), effectively restoring the behaviour prior to 4.3. Signed-off-by: David Wragg Signed-off-by: David S. Miller

vxlan: Relax MTU constraints

2016-02-10T10:50:03Z

Allow the MTU of vxlan devices without an underlying device to be set to larger values (up to a maximum based on IP packet limits and vxlan overhead). Previously, their MTUs could not be set to higher than the conventional ethernet value of 1500. This is a very arbitrary value in the context of vxlan, and prevented vxlan devices from being able to take advantage of jumbo frames etc. The default MTU remains 1500, for compatibility. Signed-off-by: David Wragg Acked-by: Roopa Prabhu Signed-off-by: David S. Miller

vxlan: fix a out of bounds access in __vxlan_find_mac

2016-01-30T04:11:16Z

The size of all_zeros_mac is 6 byte, but eth_hash() will access the 8 byte, and KASan reported the below bug: [ 8596.479031] BUG: KASan: out of bounds access in __vxlan_find_mac+0x24/0x100 at addr ffffffff841514c0 [ 8596.487647] Read of size 8 by task ip/52820 [ 8596.490818] Address belongs to variable all_zeros_mac+0x0/0x40 [ 8596.496051] CPU: 0 PID: 52820 Comm: ip Tainted: G WC 4.1.15 #1 [ 8596.503520] Hardware name: HP ProLiant DL380p Gen8, BIOS P70 02/10/2014 [ 8596.509365] ffffffff841514c0 ffff88007450f0b8 ffffffff822fa5e1 0000000000000032 [ 8596.516112] ffff88007450f150 ffff88007450f138 ffffffff812dd58c ffff88007450f1d8 [ 8596.522856] ffffffff81113b80 0000000000000282 0000000000000001 ffffffff8101ee4d [ 8596.529599] Call Trace: [ 8596.530858] [] dump_stack+0x4f/0x7b [ 8596.535080] [] kasan_report_error+0x3bc/0x3f0 [ 8596.540258] [] ? __lock_acquire+0x90/0x2140 [ 8596.545245] [] ? save_stack_trace+0x2d/0x80 [ 8596.550234] [] kasan_report+0x40/0x50 [ 8596.554647] [] ? __vxlan_find_mac+0x24/0x100 [ 8596.559729] [] __asan_load8+0x69/0xa0 [ 8596.564141] [] __vxlan_find_mac+0x24/0x100 [ 8596.569033] [] vxlan_fdb_create+0x9d/0x570 it can be fixed by enlarging the all_zeros_mac to 8 byte, although it is harmless; eth_hash() will be called in other place with the memory which is larger and equal to 8 byte. Signed-off-by: Li RongQing Signed-off-by: David S. Miller

tunnels: Allow IPv6 UDP checksums to be correctly controlled.

2016-01-21T19:10:40Z

When configuring checksums on UDP tunnels, the flags are different for IPv4 vs. IPv6 (and reversed). However, when lightweight tunnels are enabled the flags used are always the IPv4 versions, which are ignored in the IPv6 code paths. This uses the correct IPv6 flags, so checksums can be controlled appropriately. Fixes: a725e514 ("vxlan: metadata based tunneling for IPv6") Fixes: abe492b4 ("geneve: UDP checksum configuration via netlink") Signed-off-by: Jesse Gross Acked-by: Jiri Benc Signed-off-by: David S. Miller

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

2016-01-12T04:55:43Z

Conflicts: drivers/net/bonding/bond_main.c drivers/net/ethernet/mellanox/mlxsw/spectrum.h drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c The bond_main.c and mellanox switch conflicts were cases of overlapping changes. Signed-off-by: David S. Miller

udp: restrict offloads to one namespace

2016-01-10T22:28:24Z

udp tunnel offloads tend to aggregate datagrams based on inner headers. gro engine gets notified by tunnel implementations about possible offloads. The match is solely based on the port number. Imagine a tunnel bound to port 53, the offloading will look into all DNS packets and tries to aggregate them based on the inner data found within. This could lead to data corruption and malformed DNS packets. While this patch minimizes the problem and helps an administrator to find the issue by querying ip tunnel/fou, a better way would be to match on the specific destination ip address so if a user space socket is bound to the same address it will conflict. Cc: Tom Herbert Cc: Eric Dumazet Signed-off-by: Hannes Frederic Sowa Signed-off-by: David S. Miller