linux-stable.git/net/ipv6, branch v4.1.45

ipv6: Remove sit_gro_receive()

2017-10-06T00:43:20+00:00

This was backported as part of 066b300e5be4 ("tunnels: Don't apply GRO
to multiple layers of encapsulation.") but nothing uses this function,
thus resulting in this build warning:

net/ipv6/ip6_offload.c:264:25: warning: 'sit_gro_receive' defined but
not used [-Wunused-function]
 static struct sk_buff **sit_gro_receive(struct sk_buff **head,
                         ^
Just drop it for now.

Fixes: 066b300e5be4 ("tunnels: Don't apply GRO to multiple layers of encapsulation.")
Signed-off-by: Florian Fainelli 
Signed-off-by: Sasha Levin

ipv6: fix typo in fib6_net_exit()

2017-10-04T01:36:49+00:00

[ Upstream commit 32a805baf0fb70b6dbedefcd7249ac7f580f9e3b ]

IPv6 FIB should use FIB6_TABLE_HASHSZ, not FIB_TABLE_HASHSZ.

Fixes: ba1cc08d9488 ("ipv6: fix memory leak with multiple tables during netns destruction")
Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

ipv6: fix memory leak with multiple tables during netns destruction

2017-10-04T01:36:49+00:00

[ Upstream commit ba1cc08d9488c94cb8d94f545305688b72a2a300 ]

fib6_net_exit only frees the main and local tables. If another table was
created with fib6_alloc_table, we leak it when the netns is destroyed.

Fix this in the same way ip_fib_net_exit cleans up tables, by walking
through the whole hashtable of fib6_table's. We can get rid of the
special cases for local and main, since they're also part of the
hashtable.

Reproducer:
    ip netns add x
    ip -net x -6 rule add from 6003:1::/64 table 100
    ip netns del x

Reported-by: Jianlin Shi 
Fixes: 58f09b78b730 ("[NETNS][IPV6] ip6_fib - make it per network namespace")
Signed-off-by: Sabrina Dubroca 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

ipv6: accept 64k - 1 packet length in ip6_find_1stfragopt()

2017-10-04T01:36:48+00:00

[ Upstream commit 3de33e1ba0506723ab25734e098cf280ecc34756 ]

A packet length of exactly IPV6_MAXPLEN is allowed, we should
refuse parsing options only if the size is 64KiB or more.

While at it, remove one extra variable and one assignment which
were also introduced by the commit that introduced the size
check. Checking the sum 'offset + len' and only later adding
'len' to 'offset' doesn't provide any advantage over directly
summing to 'offset' and checking it.

Fixes: 6399f1fae4ec ("ipv6: avoid overflow of offset in ip6_find_1stfragopt")
Signed-off-by: Stefano Brivio 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

ipv6: reset fn->rr_ptr when replacing route

2017-10-04T01:36:31+00:00

[ Upstream commit 383143f31d7d3525a1dbff733d52fff917f82f15 ]

syzcaller reported the following use-after-free issue in rt6_select():
BUG: KASAN: use-after-free in rt6_select net/ipv6/route.c:755 [inline] at addr ffff8800bc6994e8
BUG: KASAN: use-after-free in ip6_pol_route.isra.46+0x1429/0x1470 net/ipv6/route.c:1084 at addr ffff8800bc6994e8
Read of size 4 by task syz-executor1/439628
CPU: 0 PID: 439628 Comm: syz-executor1 Not tainted 4.3.5+ #8
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
 0000000000000000 ffff88018fe435b0 ffffffff81ca384d ffff8801d3588c00
 ffff8800bc699380 ffff8800bc699500 dffffc0000000000 ffff8801d40a47c0
 ffff88018fe435d8 ffffffff81735751 ffff88018fe43660 ffff8800bc699380
Call Trace:
 [] __dump_stack lib/dump_stack.c:15 [inline]
 [] dump_stack+0xc1/0x124 lib/dump_stack.c:51
sctp: [Deprecated]: syz-executor0 (pid 439615) Use of struct sctp_assoc_value in delayed_ack socket option.
Use struct sctp_sack_info instead
 [] kasan_object_err+0x21/0x70 mm/kasan/report.c:158
 [] print_address_description mm/kasan/report.c:196 [inline]
 [] kasan_report_error+0x1b4/0x4a0 mm/kasan/report.c:285
 [] kasan_report mm/kasan/report.c:305 [inline]
 [] __asan_report_load4_noabort+0x43/0x50 mm/kasan/report.c:325
 [] rt6_select net/ipv6/route.c:755 [inline]
 [] ip6_pol_route.isra.46+0x1429/0x1470 net/ipv6/route.c:1084
 [] ip6_pol_route_output+0x81/0xb0 net/ipv6/route.c:1203
 [] fib6_rule_action+0x1f0/0x680 net/ipv6/fib6_rules.c:95
 [] fib_rules_lookup+0x2a6/0x7a0 net/core/fib_rules.c:223
 [] fib6_rule_lookup+0xd0/0x250 net/ipv6/fib6_rules.c:41
 [] ip6_route_output+0x1d6/0x2c0 net/ipv6/route.c:1224
 [] ip6_dst_lookup_tail+0x4d2/0x890 net/ipv6/ip6_output.c:943
 [] ip6_dst_lookup_flow+0x9a/0x250 net/ipv6/ip6_output.c:1079
 [] ip6_datagram_dst_update+0x538/0xd40 net/ipv6/datagram.c:91
 [] __ip6_datagram_connect net/ipv6/datagram.c:251 [inline]
 [] ip6_datagram_connect+0x518/0xe50 net/ipv6/datagram.c:272
 [] ip6_datagram_connect_v6_only+0x63/0x90 net/ipv6/datagram.c:284
 [] inet_dgram_connect+0x170/0x1f0 net/ipv4/af_inet.c:564
 [] SYSC_connect+0x1a7/0x2f0 net/socket.c:1582
 [] SyS_connect+0x29/0x30 net/socket.c:1563
 [] entry_SYSCALL_64_fastpath+0x12/0x17
Object at ffff8800bc699380, in cache ip6_dst_cache size: 384

The root cause of it is that in fib6_add_rt2node(), when it replaces an
existing route with the new one, it does not update fn->rr_ptr.
This commit resets fn->rr_ptr to NULL when it points to a route which is
replaced in fib6_add_rt2node().

Fixes: 27596472473a ("ipv6: fix ECMP route replacement")
Signed-off-by: Wei Wang 
Acked-by: Eric Dumazet 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

net: avoid skb_warn_bad_offload false positives on UFO

2017-09-10T20:36:09+00:00

[ Upstream commit 8d63bee643f1fb53e472f0e135cae4eb99d62d19 ]

skb_warn_bad_offload triggers a warning when an skb enters the GSO
stack at __skb_gso_segment that does not have CHECKSUM_PARTIAL
checksum offload set.

Commit b2504a5dbef3 ("net: reduce skb_warn_bad_offload() noise")
observed that SKB_GSO_DODGY producers can trigger the check and
that passing those packets through the GSO handlers will fix it
up. But, the software UFO handler will set ip_summed to
CHECKSUM_NONE.

When __skb_gso_segment is called from the receive path, this
triggers the warning again.

Make UFO set CHECKSUM_UNNECESSARY instead of CHECKSUM_NONE. On
Tx these two are equivalent. On Rx, this better matches the
skb state (checksum computed), as CHECKSUM_NONE here means no
checksum computed.

See also this thread for context:
http://patchwork.ozlabs.org/patch/799015/

Fixes: b2504a5dbef3 ("net: reduce skb_warn_bad_offload() noise")
Signed-off-by: Willem de Bruijn 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

ipv6: avoid overflow of offset in ip6_find_1stfragopt

2017-09-10T20:36:01+00:00

[ Upstream commit 6399f1fae4ec29fab5ec76070435555e256ca3a6 ]

In some cases, offset can overflow and can cause an infinite loop in
ip6_find_1stfragopt(). Make it unsigned int to prevent the overflow, and
cap it at IPV6_MAXPLEN, since packets larger than that should be invalid.

This problem has been here since before the beginning of git history.

Signed-off-by: Sabrina Dubroca 
Acked-by: Hannes Frederic Sowa 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

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

2017-09-10T20:35:53+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

ipv6: dad: don't remove dynamic addresses if link is down

2017-07-31T17:37:54+00:00

[ Upstream commit ec8add2a4c9df723c94a863b8fcd6d93c472deed ]

Currently, when the link for $DEV is down, this command succeeds but the
address is removed immediately by DAD (1):

    ip addr add 1111::12/64 dev $DEV valid_lft 3600 preferred_lft 1800

In the same situation, this will succeed and not remove the address (2):

    ip addr add 1111::12/64 dev $DEV
    ip addr change 1111::12/64 dev $DEV valid_lft 3600 preferred_lft 1800

The comment in addrconf_dad_begin() when !IF_READY makes it look like
this is the intended behavior, but doesn't explain why:

     * If the device is not ready:
     * - keep it tentative if it is a permanent address.
     * - otherwise, kill it.

We clearly cannot prevent userspace from doing (2), but we can make (1)
work consistently with (2).

addrconf_dad_stop() is only called in two cases: if DAD failed, or to
skip DAD when the link is down. In that second case, the fix is to avoid
deleting the address, like we already do for permanent addresses.

Fixes: 3c21edbd1137 ("[IPV6]: Defer IPv6 device initialization until the link becomes ready.")
Signed-off-by: Sabrina Dubroca 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

ipv6: fix calling in6_ifa_hold incorrectly for dad work

2017-07-31T17:37:48+00:00

[ Upstream commit f8a894b218138888542a5058d0e902378fd0d4ec ]

Now when starting the dad work in addrconf_mod_dad_work, if the dad work
is idle and queued, it needs to hold ifa.

The problem is there's one gap in [1], during which if the pending dad work
is removed elsewhere. It will miss to hold ifa, but the dad word is still
idea and queue.

        if (!delayed_work_pending(&ifp->dad_work))
                in6_ifa_hold(ifp);
                    <--------------[1]
        mod_delayed_work(addrconf_wq, &ifp->dad_work, delay);

An use-after-free issue can be caused by this.

Chen Wei found this issue when WARN_ON(!hlist_unhashed(&ifp->addr_lst)) in
net6_ifa_finish_destroy was hit because of it.

As Hannes' suggestion, this patch is to fix it by holding ifa first in
addrconf_mod_dad_work, then calling mod_delayed_work and putting ifa if
the dad_work is already in queue.

Note that this patch did not choose to fix it with:

  if (!mod_delayed_work(delay))
          in6_ifa_hold(ifp);

As with it, when delay == 0, dad_work would be scheduled immediately, all
addrconf_mod_dad_work(0) callings had to be moved under ifp->lock.

Reported-by: Wei Chen 
Suggested-by: Hannes Frederic Sowa 
Acked-by: Hannes Frederic Sowa 
Signed-off-by: Xin Long 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin