linux-toradex.git/net/ipv6/ip6_fib.c, branch v4.4.148

ipv6: fix typo in fib6_net_exit()

2017-09-27T09:00:12+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: Greg Kroah-Hartman

ipv6: fix memory leak with multiple tables during netns destruction

2017-09-27T09:00:11+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: Greg Kroah-Hartman

ipv6: fix sparse warning on rt6i_node

2017-09-27T09:00:10+00:00

[ Upstream commit 4e587ea71bf924f7dac621f1351653bd41e446cb ]

Commit c5cff8561d2d adds rcu grace period before freeing fib6_node. This
generates a new sparse warning on rt->rt6i_node related code:
  net/ipv6/route.c:1394:30: error: incompatible types in comparison
  expression (different address spaces)
  ./include/net/ip6_fib.h:187:14: error: incompatible types in comparison
  expression (different address spaces)

This commit adds "__rcu" tag for rt6i_node and makes sure corresponding
rcu API is used for it.
After this fix, sparse no longer generates the above warning.

Fixes: c5cff8561d2d ("ipv6: add rcu grace period before freeing fib6_node")
Signed-off-by: Wei Wang 
Acked-by: Eric Dumazet 
Acked-by: Martin KaFai Lau 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

ipv6: add rcu grace period before freeing fib6_node

2017-09-27T09:00:10+00:00

[ Upstream commit c5cff8561d2d0006e972bd114afd51f082fee77c ]

We currently keep rt->rt6i_node pointing to the fib6_node for the route.
And some functions make use of this pointer to dereference the fib6_node
from rt structure, e.g. rt6_check(). However, as there is neither
refcount nor rcu taken when dereferencing rt->rt6i_node, it could
potentially cause crashes as rt->rt6i_node could be set to NULL by other
CPUs when doing a route deletion.
This patch introduces an rcu grace period before freeing fib6_node and
makes sure the functions that dereference it takes rcu_read_lock().

Note: there is no "Fixes" tag because this bug was there in a very
early stage.

Signed-off-by: Wei Wang 
Acked-by: Eric Dumazet 
Acked-by: Martin KaFai Lau 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

ipv6: repair fib6 tree in failure case

2017-08-30T08:19:20+00:00

[ Upstream commit 348a4002729ccab8b888b38cbc099efa2f2a2036 ]

In fib6_add(), it is possible that fib6_add_1() picks an intermediate
node and sets the node's fn->leaf to NULL in order to add this new
route. However, if fib6_add_rt2node() fails to add the new
route for some reason, fn->leaf will be left as NULL and could
potentially cause crash when fn->leaf is accessed in fib6_locate().
This patch makes sure fib6_repair_tree() is called to properly repair
fn->leaf in the above failure case.

Here is the syzkaller reported general protection fault in fib6_locate:
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] SMP KASAN
Modules linked in:
CPU: 0 PID: 40937 Comm: syz-executor3 Not tainted
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
task: ffff8801d7d64100 ti: ffff8801d01a0000 task.ti: ffff8801d01a0000
RIP: 0010:[]  [] __ipv6_prefix_equal64_half include/net/ipv6.h:475 [inline]
RIP: 0010:[]  [] ipv6_prefix_equal include/net/ipv6.h:492 [inline]
RIP: 0010:[]  [] fib6_locate_1 net/ipv6/ip6_fib.c:1210 [inline]
RIP: 0010:[]  [] fib6_locate+0x281/0x3c0 net/ipv6/ip6_fib.c:1233
RSP: 0018:ffff8801d01a36a8  EFLAGS: 00010202
RAX: 0000000000000020 RBX: ffff8801bc790e00 RCX: ffffc90002983000
RDX: 0000000000001219 RSI: ffff8801d01a37a0 RDI: 0000000000000100
RBP: ffff8801d01a36f0 R08: 00000000000000ff R09: 0000000000000000
R10: 0000000000000003 R11: 0000000000000000 R12: 0000000000000001
R13: dffffc0000000000 R14: ffff8801d01a37a0 R15: 0000000000000000
FS:  00007f6afd68c700(0000) GS:ffff8801db400000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000004c6340 CR3: 00000000ba41f000 CR4: 00000000001426f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Stack:
 ffff8801d01a37a8 ffff8801d01a3780 ffffed003a0346f5 0000000c82a23ea0
 ffff8800b7bd7700 ffff8801d01a3780 ffff8800b6a1c940 ffffffff82a23ea0
 ffff8801d01a3920 ffff8801d01a3748 ffffffff82a223d6 ffff8801d7d64988
Call Trace:
 [] ip6_route_del+0x106/0x570 net/ipv6/route.c:2109
 [] inet6_rtm_delroute+0xfd/0x100 net/ipv6/route.c:3075
 [] rtnetlink_rcv_msg+0x549/0x7a0 net/core/rtnetlink.c:3450
 [] netlink_rcv_skb+0x141/0x370 net/netlink/af_netlink.c:2281
 [] rtnetlink_rcv+0x2f/0x40 net/core/rtnetlink.c:3456
 [] netlink_unicast_kernel net/netlink/af_netlink.c:1206 [inline]
 [] netlink_unicast+0x518/0x750 net/netlink/af_netlink.c:1232
 [] netlink_sendmsg+0x8ce/0xc30 net/netlink/af_netlink.c:1778
 [] sock_sendmsg_nosec net/socket.c:609 [inline]
 [] sock_sendmsg+0xcf/0x110 net/socket.c:619
 [] sock_write_iter+0x222/0x3a0 net/socket.c:834
 [] new_sync_write+0x1dd/0x2b0 fs/read_write.c:478
 [] __vfs_write+0xe4/0x110 fs/read_write.c:491
 [] vfs_write+0x178/0x4b0 fs/read_write.c:538
 [] SYSC_write fs/read_write.c:585 [inline]
 [] SyS_write+0xd9/0x1b0 fs/read_write.c:577
 [] entry_SYSCALL_64_fastpath+0x12/0x17

Note: there is no "Fixes" tag as this seems to be a bug introduced
very early.

Signed-off-by: Wei Wang 
Acked-by: Eric Dumazet 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

ipv6: reset fn->rr_ptr when replacing route

2017-08-30T08:19:20+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: Greg Kroah-Hartman

net: ipv6: Compare lwstate in detecting duplicate nexthops

2017-07-21T05:44:55+00:00

commit f06b7549b79e29a672336d4e134524373fb7a232 upstream.

Lennert reported a failure to add different mpls encaps in a multipath
route:

  $ ip -6 route add 1234::/16 \
        nexthop encap mpls 10 via fe80::1 dev ens3 \
        nexthop encap mpls 20 via fe80::1 dev ens3
  RTNETLINK answers: File exists

The problem is that the duplicate nexthop detection does not compare
lwtunnel configuration. Add it.

Fixes: 19e42e451506 ("ipv6: support for fib route lwtunnel encap attributes")
Signed-off-by: David Ahern 
Reported-by: João Taveira Araújo 
Reported-by: Lennert Buytenhek 
Acked-by: Roopa Prabhu 
Tested-by: Lennert Buytenhek 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

ipv6: Do not leak throw route references

2017-07-05T12:37:14+00:00

[ Upstream commit 07f615574f8ac499875b21c1142f26308234a92c ]

While commit 73ba57bfae4a ("ipv6: fix backtracking for throw routes")
does good job on error propagation to the fib_rules_lookup()
in fib rules core framework that also corrects throw routes
handling, it does not solve route reference leakage problem
happened when we return -EAGAIN to the fib_rules_lookup()
and leave routing table entry referenced in arg->result.

If rule with matched throw route isn't last matched in the
list we overwrite arg->result losing reference on throw
route stored previously forever.

We also partially revert commit ab997ad40839 ("ipv6: fix the
incorrect return value of throw route") since we never return
routing table entry with dst.error == -EAGAIN when
CONFIG_IPV6_MULTIPLE_TABLES is on. Also there is no point
to check for RTF_REJECT flag since it is always set throw
route.

Fixes: 73ba57bfae4a ("ipv6: fix backtracking for throw routes")
Signed-off-by: Serhey Popovych 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

ipv6: make ECMP route replacement less greedy

2017-03-22T11:04:17+00:00

[ Upstream commit 67e194007be08d071294456274dd53e0a04fdf90 ]

Commit 27596472473a ("ipv6: fix ECMP route replacement") introduced a
loop that removes all siblings of an ECMP route that is being
replaced. However, this loop doesn't stop when it has replaced
siblings, and keeps removing other routes with a higher metric.
We also end up triggering the WARN_ON after the loop, because after
this nsiblings < 0.

Instead, stop the loop when we have taken care of all routes with the
same metric as the route being replaced.

  Reproducer:
  ===========
    #!/bin/sh

    ip netns add ns1
    ip netns add ns2
    ip -net ns1 link set lo up

    for x in 0 1 2 ; do
        ip link add veth$x netns ns2 type veth peer name eth$x netns ns1
        ip -net ns1 link set eth$x up
        ip -net ns2 link set veth$x up
    done

    ip -net ns1 -6 r a 2000::/64 nexthop via fe80::0 dev eth0 \
            nexthop via fe80::1 dev eth1 nexthop via fe80::2 dev eth2
    ip -net ns1 -6 r a 2000::/64 via fe80::42 dev eth0 metric 256
    ip -net ns1 -6 r a 2000::/64 via fe80::43 dev eth0 metric 2048

    echo "before replace, 3 routes"
    ip -net ns1 -6 r | grep -v '^fe80\|^ff00'
    echo

    ip -net ns1 -6 r c 2000::/64 nexthop via fe80::4 dev eth0 \
            nexthop via fe80::5 dev eth1 nexthop via fe80::6 dev eth2

    echo "after replace, only 2 routes, metric 2048 is gone"
    ip -net ns1 -6 r | grep -v '^fe80\|^ff00'

Fixes: 27596472473a ("ipv6: fix ECMP route replacement")
Signed-off-by: Sabrina Dubroca 
Acked-by: Nicolas Dichtel 
Reviewed-by: Xin Long 
Reviewed-by: Michal Kubecek 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

ipv6: Fix mem leak in rt6i_pcpu

2016-07-27T16:47:31+00:00

[ Upstream commit 903ce4abdf374e3365d93bcb3df56c62008835ba ]

It was first reported and reproduced by Petr (thanks!) in
https://bugzilla.kernel.org/show_bug.cgi?id=119581

free_percpu(rt->rt6i_pcpu) used to always happen in ip6_dst_destroy().

However, after fixing a deadlock bug in
commit 9c7370a166b4 ("ipv6: Fix a potential deadlock when creating pcpu rt"),
free_percpu() is not called before setting non_pcpu_rt->rt6i_pcpu to NULL.

It is worth to note that rt6i_pcpu is protected by table->tb6_lock.

kmemleak somehow did not report it.  We nailed it down by
observing the pcpu entries in /proc/vmallocinfo (first suggested
by Hannes, thanks!).

Signed-off-by: Martin KaFai Lau 
Fixes: 9c7370a166b4 ("ipv6: Fix a potential deadlock when creating pcpu rt")
Reported-by: Petr Novopashenniy 
Tested-by: Petr Novopashenniy 
Acked-by: Hannes Frederic Sowa 
Cc: Hannes Frederic Sowa 
Cc: Petr Novopashenniy 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman