linux.git/net, branch v3.14.31

ipvs: uninitialized data with IP_VS_IPV6

2015-01-30T01:40:50+00:00

commit 3b05ac3824ed9648c0d9c02d51d9b54e4e7e874f upstream.

The app_tcp_pkt_out() function expects "*diff" to be set and ends up
using uninitialized data if CONFIG_IP_VS_IPV6 is turned on.

The same issue is there in app_tcp_pkt_in().  Thanks to Julian Anastasov
for noticing that.

Signed-off-by: Dan Carpenter 
Acked-by: Julian Anastasov 
Signed-off-by: Simon Horman 
Signed-off-by: Greg Kroah-Hartman

netfilter: nfnetlink: validate nfnetlink header from batch

2015-01-30T01:40:50+00:00

commit 9ea2aa8b7dba9e99544c4187cc298face254569f upstream.

Make sure there is enough room for the nfnetlink header in the
netlink messages that are part of the batch. There is a similar
check in netlink_rcv_skb().

Signed-off-by: Pablo Neira Ayuso 
Signed-off-by: Greg Kroah-Hartman

net: fix creation adjacent device symlinks

2015-01-27T16:18:59+00:00

commit 7ce64c79c4decdeb1afe0bf2f6ef834b382871d1 upstream.

__netdev_adjacent_dev_insert may add adjust device of different net
namespace, without proper check it leads to emergence of broken
sysfs links from/to devices in another namespace.
Fix: rewrite netdev_adjacent_is_neigh_list macro as a function,
     move net_eq check into netdev_adjacent_is_neigh_list.
     (thanks David)
     related to: 4c75431ac3520631f1d9e74aa88407e6374dbbc4

Signed-off-by: Alexander Fomichev 
Signed-off-by: David S. Miller 
Cc: Miquel van Smoorenburg 
Signed-off-by: Greg Kroah-Hartman

net: prevent of emerging cross-namespace symlinks

2015-01-27T16:18:59+00:00

commit 4c75431ac3520631f1d9e74aa88407e6374dbbc4 upstream.

Code manipulating sysfs symlinks on adjacent net_devices(s)
currently doesn't take into account that devices potentially
belong to different namespaces.

This patch trying to fix an issue as follows:
- check for net_ns before creating / deleting symlink.
  for now only netdev_adjacent_rename_links and
  __netdev_adjacent_dev_remove are affected, afaics
  __netdev_adjacent_dev_insert implies both net_devs
  belong to the same namespace.
- Drop all existing symlinks to / from all adj_devs before
  switching namespace and recreate them just after.

Signed-off-by: Alexander Y. Fomichev 
Signed-off-by: David S. Miller 
Cc: Miquel van Smoorenburg 
Signed-off-by: Greg Kroah-Hartman

netfilter: ipset: small potential read beyond the end of buffer

2015-01-27T16:18:59+00:00

commit 2196937e12b1b4ba139806d132647e1651d655df upstream.

We could be reading 8 bytes into a 4 byte buffer here.  It seems
harmless but adding a check is the right thing to do and it silences a
static checker warning.

Signed-off-by: Dan Carpenter 
Acked-by: Jozsef Kadlecsik 
Signed-off-by: Pablo Neira Ayuso 
Signed-off-by: Greg Kroah-Hartman

cfg80211: Fix 160 MHz channels with 80+80 and 160 MHz drivers

2015-01-27T16:18:55+00:00

commit 08f6f147773b23b765b94633a8eaa82e7defcf4c upstream.

The VHT supported channel width field is a two bit integer, not a
bitfield. cfg80211_chandef_usable() was interpreting it incorrectly and
ended up rejecting 160 MHz channel width if the driver indicated support
for both 160 and 80+80 MHz channels.

Fixes: 3d9d1d6656a73 ("nl80211/cfg80211: support VHT channel configuration")
       (however, no real drivers had 160 MHz support it until 3.16)
Signed-off-by: Jouni Malinen 
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman

cfg80211: avoid mem leak on driver hint set

2015-01-27T16:18:54+00:00

commit 34f05f543f02350e920bddb7660ffdd4697aaf60 upstream.

In the already-set and intersect case of a driver-hint, the previous
wiphy regdomain was not freed before being reset with a copy of the
cfg80211 regdomain.

Signed-off-by: Arik Nemtsov 
Acked-by: Luis R. Rodriguez 
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman

cfg80211: don't WARN about two consecutive Country IE hint

2015-01-27T16:18:54+00:00

commit 70dcec5a488a7b81779190ac8089475fe4b8b962 upstream.

This can happen and there is no point in added more
detection code lower in the stack. Catching these in one
single point (cfg80211) is enough. Stop WARNING about this
case.

This fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=89001

Fixes: 2f1c6c572d7b ("cfg80211: process non country IE conflicting first")
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman

net/core: Handle csum for CHECKSUM_COMPLETE VXLAN forwarding

2015-01-27T16:18:53+00:00

[ Upstream commit 2c26d34bbcc0b3f30385d5587aa232289e2eed8e ]

When using VXLAN tunnels and a sky2 device, I have experienced
checksum failures of the following type:

[ 4297.761899] eth0: hw csum failure
[...]
[ 4297.765223] Call Trace:
[ 4297.765224]    [] dump_stack+0x46/0x58
[ 4297.765235]  [] netdev_rx_csum_fault+0x42/0x50
[ 4297.765238]  [] ? skb_push+0x40/0x40
[ 4297.765240]  [] __skb_checksum_complete+0xbc/0xd0
[ 4297.765243]  [] tcp_v4_rcv+0x2e2/0x950
[ 4297.765246]  [] ? ip_rcv_finish+0x360/0x360

	These are reliably reproduced in a network topology of:

container:eth0 == host(OVS VXLAN on VLAN) == bond0 == eth0 (sky2) -> switch

	When VXLAN encapsulated traffic is received from a similarly
configured peer, the above warning is generated in the receive
processing of the encapsulated packet.  Note that the warning is
associated with the container eth0.

        The skbs from sky2 have ip_summed set to CHECKSUM_COMPLETE, and
because the packet is an encapsulated Ethernet frame, the checksum
generated by the hardware includes the inner protocol and Ethernet
headers.

	The receive code is careful to update the skb->csum, except in
__dev_forward_skb, as called by dev_forward_skb.  __dev_forward_skb
calls eth_type_trans, which in turn calls skb_pull_inline(skb, ETH_HLEN)
to skip over the Ethernet header, but does not update skb->csum when
doing so.

	This patch resolves the problem by adding a call to
skb_postpull_rcsum to update the skb->csum after the call to
eth_type_trans.

Signed-off-by: Jay Vosburgh 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

tcp: Do not apply TSO segment limit to non-TSO packets

2015-01-27T16:18:53+00:00

[ Upstream commit 843925f33fcc293d80acf2c5c8a78adf3344d49b ]

Thomas Jarosch reported IPsec TCP stalls when a PMTU event occurs.

In fact the problem was completely unrelated to IPsec.  The bug is
also reproducible if you just disable TSO/GSO.

The problem is that when the MSS goes down, existing queued packet
on the TX queue that have not been transmitted yet all look like
TSO packets and get treated as such.

This then triggers a bug where tcp_mss_split_point tells us to
generate a zero-sized packet on the TX queue.  Once that happens
we're screwed because the zero-sized packet can never be removed
by ACKs.

Fixes: 1485348d242 ("tcp: Apply device TSO segment limit earlier")
Reported-by: Thomas Jarosch 
Signed-off-by: Herbert Xu 

Cheers,
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman