linux-toradex.git/net, branch v4.4.80

xfrm: Don't use sk_family for socket policy lookups

2017-08-07T02:19:46+00:00

commit 4c86d77743a54fb2d8a4d18a037a074c892bb3be upstream.

On IPv4-mapped IPv6 addresses sk_family is AF_INET6,
but the flow informations are created based on AF_INET.
So the routing set up 'struct flowi4' but we try to
access 'struct flowi6' what leads to an out of bounds
access. Fix this by using the family we get with the
dst_entry, like we do it for the standard policy lookup.

Reported-by: Dmitry Vyukov 
Tested-by: Dmitry Vyukov 
Signed-off-by: Steffen Klassert 
Signed-off-by: Greg Kroah-Hartman

ipv6: Should use consistent conditional judgement for ip6 fragment between __ip6_append_data and ip6_finish_output

2017-08-07T02:19:44+00:00

[ Upstream commit e4c5e13aa45c23692e4acf56f0b3533f328199b2 ]

There is an inconsistent conditional judgement between __ip6_append_data
and ip6_finish_output functions, the variable length in __ip6_append_data
just include the length of application's payload and udp6 header, don't
include the length of ipv6 header, but in ip6_finish_output use
(skb->len > ip6_skb_dst_mtu(skb)) as judgement, and skb->len include the
length of ipv6 header.

That causes some particular application's udp6 payloads whose length are
between (MTU - IPv6 Header) and MTU were fragmented by ip6_fragment even
though the rst->dev support UFO feature.

Add the length of ipv6 header to length in __ip6_append_data to keep
consistent conditional judgement as ip6_finish_output for ip6 fragment.

Signed-off-by: Zheng Li 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

net: skb_needs_check() accepts CHECKSUM_NONE for tx

2017-08-07T02:19:43+00:00

commit 6e7bc478c9a006c701c14476ec9d389a484b4864 upstream.

My recent change missed fact that UFO would perform a complete
UDP checksum before segmenting in frags.

In this case skb->ip_summed is set to CHECKSUM_NONE.

We need to add this valid case to skb_needs_check()

Fixes: b2504a5dbef3 ("net: reduce skb_warn_bad_offload() noise")
Signed-off-by: Eric Dumazet 
Cc: Willem de Bruijn 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

vlan: Propagate MAC address to VLANs

2017-08-07T02:19:43+00:00

commit 308453aa9156a3b8ee382c0949befb507a32b0c1 upstream.

The MAC address of the physical interface is only copied to the VLAN
when it is first created, resulting in an inconsistency after MAC
address changes of only newly created VLANs having an up-to-date MAC.

The VLANs should continue inheriting the MAC address of the physical
interface until the VLAN MAC address is explicitly set to any value.
This allows IPv6 EUI64 addresses for the VLAN to reflect any changes
to the MAC of the physical interface and thus for DAD to behave as
expected.

Signed-off-by: Mike Manning 
Signed-off-by: David S. Miller 
Signed-off-by: Sumit Semwal 
Signed-off-by: Greg Kroah-Hartman

net: reduce skb_warn_bad_offload() noise

2017-08-07T02:19:38+00:00

commit b2504a5dbef3305ef41988ad270b0e8ec289331c upstream.

Dmitry reported warnings occurring in __skb_gso_segment() [1]

All SKB_GSO_DODGY producers can allow user space to feed
packets that trigger the current check.

We could prevent them from doing so, rejecting packets, but
this might add regressions to existing programs.

It turns out our SKB_GSO_DODGY handlers properly set up checksum
information that is needed anyway when packets needs to be segmented.

By checking again skb_needs_check() after skb_mac_gso_segment(),
we should remove these pesky warnings, at a very minor cost.

With help from Willem de Bruijn

[1]
WARNING: CPU: 1 PID: 6768 at net/core/dev.c:2439 skb_warn_bad_offload+0x2af/0x390 net/core/dev.c:2434
lo: caps=(0x000000a2803b7c69, 0x0000000000000000) len=138 data_len=0 gso_size=15883 gso_type=4 ip_summed=0
Kernel panic - not syncing: panic_on_warn set ...

CPU: 1 PID: 6768 Comm: syz-executor1 Not tainted 4.9.0 #5
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
 ffff8801c063ecd8 ffffffff82346bdf ffffffff00000001 1ffff100380c7d2e
 ffffed00380c7d26 0000000041b58ab3 ffffffff84b37e38 ffffffff823468f1
 ffffffff84820740 ffffffff84f289c0 dffffc0000000000 ffff8801c063ee20
Call Trace:
 [] __dump_stack lib/dump_stack.c:15 [inline]
 [] dump_stack+0x2ee/0x3ef lib/dump_stack.c:51
 [] panic+0x1fb/0x412 kernel/panic.c:179
 [] __warn+0x1c4/0x1e0 kernel/panic.c:542
 [] warn_slowpath_fmt+0xc5/0x100 kernel/panic.c:565
 [] skb_warn_bad_offload+0x2af/0x390 net/core/dev.c:2434
 [] __skb_gso_segment+0x482/0x780 net/core/dev.c:2706
 [] skb_gso_segment include/linux/netdevice.h:3985 [inline]
 [] validate_xmit_skb+0x5c9/0xc20 net/core/dev.c:2969
 [] __dev_queue_xmit+0xe6b/0x1e70 net/core/dev.c:3383
 [] dev_queue_xmit+0x17/0x20 net/core/dev.c:3424
 [] packet_snd net/packet/af_packet.c:2930 [inline]
 [] packet_sendmsg+0x32ed/0x4d30 net/packet/af_packet.c:2955
 [] sock_sendmsg_nosec net/socket.c:621 [inline]
 [] sock_sendmsg+0xca/0x110 net/socket.c:631
 [] ___sys_sendmsg+0x8fa/0x9f0 net/socket.c:1954
 [] __sys_sendmsg+0x138/0x300 net/socket.c:1988
 [] SYSC_sendmsg net/socket.c:1999 [inline]
 [] SyS_sendmsg+0x2d/0x50 net/socket.c:1995
 [] entry_SYSCALL_64_fastpath+0x1f/0xc2

Signed-off-by: Eric Dumazet 
Reported-by: Dmitry Vyukov  
Cc: Willem de Bruijn 
Signed-off-by: David S. Miller 
Cc: Mark Salyzyn 
Signed-off-by: Greg Kroah-Hartman

af_key: Add lock to key dump

2017-08-07T02:19:38+00:00

commit 89e357d83c06b6fac581c3ca7f0ee3ae7e67109e upstream.

A dump may come in the middle of another dump, modifying its dump
structure members. This race condition will result in NULL pointer
dereference in kernel. So add a lock to prevent that race.

Fixes: 83321d6b9872 ("[AF_KEY]: Dump SA/SP entries non-atomically")
Signed-off-by: Yuejie Shi 
Signed-off-by: Steffen Klassert 
Signed-off-by: Mark Salyzyn 
Signed-off-by: Greg Kroah-Hartman

ipvs: SNAT packet replies only for NATed connections

2017-07-27T22:06:05+00:00

commit 3c5ab3f395d66a9e4e937fcfdf6ebc63894f028b upstream.

We do not check if packet from real server is for NAT
connection before performing SNAT. This causes problems
for setups that use DR/TUN and allow local clients to
access the real server directly, for example:

- local client in director creates IPVS-DR/TUN connection
CIP->VIP and the request packets are routed to RIP.
Talks are finished but IPVS connection is not expired yet.

- second local client creates non-IPVS connection CIP->RIP
with same reply tuple RIP->CIP and when replies are received
on LOCAL_IN we wrongly assign them for the first client
connection because RIP->CIP matches the reply direction.
As result, IPVS SNATs replies for non-IPVS connections.

The problem is more visible to local UDP clients but in rare
cases it can happen also for TCP or remote clients when the
real server sends the reply traffic via the director.

So, better to be more precise for the reply traffic.
As replies are not expected for DR/TUN connections, better
to not touch them.

Reported-by: Nick Moriarty 
Tested-by: Nick Moriarty 
Signed-off-by: Julian Anastasov 
Signed-off-by: Simon Horman 
Signed-off-by: Greg Kroah-Hartman

af_key: Fix sadb_x_ipsecrequest parsing

2017-07-27T22:06:05+00:00

commit 096f41d3a8fcbb8dde7f71379b1ca85fe213eded upstream.

The parsing of sadb_x_ipsecrequest is broken in a number of ways.
First of all we're not verifying sadb_x_ipsecrequest_len.  This
is needed when the structure carries addresses at the end.  Worse
we don't even look at the length when we parse those optional
addresses.

The migration code had similar parsing code that's better but
it also has some deficiencies.  The length is overcounted first
of all as it includes the header itself.  It also fails to check
the length before dereferencing the sa_family field.

This patch fixes those problems in parse_sockaddr_pair and then
uses it in parse_ipsecrequest.

Reported-by: Andrey Konovalov 
Signed-off-by: Herbert Xu 
Signed-off-by: Steffen Klassert 
Signed-off-by: Greg Kroah-Hartman

Bluetooth: use constant time memory comparison for secret values

2017-07-27T22:06:04+00:00

commit 329d82309824ff1082dc4a91a5bbed8c3bec1580 upstream.

This file is filled with complex cryptography. Thus, the comparisons of
MACs and secret keys and curve points and so forth should not add timing
attacks, which could either result in a direct forgery, or, given the
complexity, some other type of attack.

Signed-off-by: Jason A. Donenfeld 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Greg Kroah-Hartman

NFC: Add sockaddr length checks before accessing sa_family in bind handlers

2017-07-27T22:06:03+00:00

commit f6a5885fc4d68e7f25ffb42b9d8d80aebb3bacbb upstream.

Verify that the caller-provided sockaddr structure is large enough to
contain the sa_family field, before accessing it in bind() handlers of the
AF_NFC socket. Since the syscall doesn't enforce a minimum size of the
corresponding memory region, very short sockaddrs (zero or one byte long)
result in operating on uninitialized memory while referencing .sa_family.

Signed-off-by: Mateusz Jurczyk 
Signed-off-by: Samuel Ortiz 
Signed-off-by: Greg Kroah-Hartman