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

ip6_gre: release cached dst on tunnel removal

2015-08-25T21:33:00+00:00

When a tunnel is deleted, the cached dst entry should be released.

This problem may prevent the removal of a netns (seen with a x-netns IPv6
gre tunnel):
  unregister_netdevice: waiting for lo to become free. Usage count = 3

CC: Dmitry Kozlov 
Fixes: c12b395a4664 ("gre: Support GRE over IPv6")
Signed-off-by: huaibin Wang 
Signed-off-by: Nicolas Dichtel 
Signed-off-by: David S. Miller

ipv6: Fix a potential deadlock when creating pcpu rt

2015-08-17T21:28:03+00:00

rt6_make_pcpu_route() is called under read_lock(&table->tb6_lock).
rt6_make_pcpu_route() calls ip6_rt_pcpu_alloc(rt) which then
calls dst_alloc().  dst_alloc() _may_ call ip6_dst_gc() which takes
the write_lock(&tabl->tb6_lock).  A visualized version:

read_lock(&table->tb6_lock);
rt6_make_pcpu_route();
=> ip6_rt_pcpu_alloc();
=> dst_alloc();
=> ip6_dst_gc();
=> write_lock(&table->tb6_lock); /* oops */

The fix is to do a read_unlock first before calling ip6_rt_pcpu_alloc().

A reported stack:

[141625.537638] INFO: rcu_sched self-detected stall on CPU { 27}  (t=60000 jiffies g=4159086 c=4159085 q=2139)
[141625.547469] Task dump for CPU 27:
[141625.550881] mtr             R  running task        0 22121  22081 0x00000008
[141625.558069]  0000000000000000 ffff88103f363d98 ffffffff8106e488 000000000000001b
[141625.565641]  ffffffff81684900 ffff88103f363db8 ffffffff810702b0 0000000008000000
[141625.573220]  ffffffff81684900 ffff88103f363de8 ffffffff8108df9f ffff88103f375a00
[141625.580803] Call Trace:
[141625.583345]    [] sched_show_task+0xc1/0xc6
[141625.589650]  [] dump_cpu_task+0x35/0x39
[141625.595144]  [] rcu_dump_cpu_stacks+0x6a/0x8c
[141625.601320]  [] rcu_check_callbacks+0x1f6/0x5d4
[141625.607669]  [] update_process_times+0x2a/0x4f
[141625.613925]  [] tick_sched_handle+0x32/0x3e
[141625.619923]  [] tick_sched_timer+0x35/0x5c
[141625.625830]  [] __hrtimer_run_queues+0x8f/0x18d
[141625.632171]  [] hrtimer_interrupt+0xa0/0x166
[141625.638258]  [] local_apic_timer_interrupt+0x4e/0x52
[141625.645036]  [] smp_apic_timer_interrupt+0x39/0x4a
[141625.651643]  [] apic_timer_interrupt+0x68/0x70
[141625.657895]    [] ? dst_destroy+0x7c/0xb5
[141625.664188]  [] ? fib6_flush_trees+0x20/0x20
[141625.670272]  [] ? queue_write_lock_slowpath+0x60/0x6f
[141625.677140]  [] _raw_write_lock_bh+0x23/0x25
[141625.683218]  [] __fib6_clean_all+0x40/0x82
[141625.689124]  [] ? fib6_flush_trees+0x20/0x20
[141625.695207]  [] fib6_clean_all+0xe/0x10
[141625.700854]  [] fib6_run_gc+0x79/0xc8
[141625.706329]  [] ip6_dst_gc+0x85/0xf9
[141625.711718]  [] dst_alloc+0x55/0x159
[141625.717105]  [] __ip6_dst_alloc.isra.32+0x19/0x63
[141625.723620]  [] ip6_pol_route+0x36a/0x3e8
[141625.729441]  [] ip6_pol_route_output+0x11/0x13
[141625.735700]  [] fib6_rule_action+0xa7/0x1bf
[141625.741698]  [] ? ip6_pol_route_input+0x17/0x17
[141625.748043]  [] fib_rules_lookup+0xb5/0x12a
[141625.754050]  [] ? poll_select_copy_remaining+0xf9/0xf9
[141625.761002]  [] fib6_rule_lookup+0x37/0x5c
[141625.766914]  [] ? ip6_pol_route_input+0x17/0x17
[141625.773260]  [] ip6_route_output+0x7a/0x82
[141625.779177]  [] ip6_dst_lookup_tail+0x53/0x112
[141625.785437]  [] ip6_dst_lookup_flow+0x2a/0x6b
[141625.791604]  [] rawv6_sendmsg+0x407/0x9b6
[141625.797423]  [] ? do_ipv6_setsockopt.isra.8+0xd87/0xde2
[141625.804464]  [] inet_sendmsg+0x57/0x8e
[141625.810028]  [] sock_sendmsg+0x2e/0x3c
[141625.815588]  [] SyS_sendto+0xfe/0x143
[141625.821063]  [] ? rawv6_setsockopt+0x5e/0x67
[141625.827146]  [] ? sock_common_setsockopt+0xf/0x11
[141625.833660]  [] ? SyS_setsockopt+0x81/0xa2
[141625.839565]  [] entry_SYSCALL_64_fastpath+0x12/0x6a

Fixes: d52d3997f843 ("pv6: Create percpu rt6_info")
Signed-off-by: Martin KaFai Lau 
CC: Hannes Frederic Sowa 
Reported-by: Steinar H. Gunderson 
Signed-off-by: David S. Miller

ipv6: Add rt6_make_pcpu_route()

2015-08-17T21:28:03+00:00

It is a prep work for fixing a potential deadlock when creating
a pcpu rt.

The current rt6_get_pcpu_route() will also create a pcpu rt if one does not
exist.  This patch moves the pcpu rt creation logic into another function,
rt6_make_pcpu_route().

Signed-off-by: Martin KaFai Lau 
CC: Hannes Frederic Sowa 
Signed-off-by: David S. Miller

ipv6: Remove un-used argument from ip6_dst_alloc()

2015-08-17T21:28:03+00:00

After 4b32b5ad31a6 ("ipv6: Stop rt6_info from using inet_peer's metrics"),
ip6_dst_alloc() does not need the 'table' argument.  This patch
cleans it up.

Signed-off-by: Martin KaFai Lau 
CC: Hannes Frederic Sowa 
Signed-off-by: David S. Miller

net: fix wrong skb_get() usage / crash in IGMP/MLD parsing code

2015-08-14T00:08:39+00:00

The recent refactoring of the IGMP and MLD parsing code into
ipv6_mc_check_mld() / ip_mc_check_igmp() introduced a potential crash /
BUG() invocation for bridges:

I wrongly assumed that skb_get() could be used as a simple reference
counter for an skb which is not the case. skb_get() bears additional
semantics, a user count. This leads to a BUG() invocation in
pskb_expand_head() / kernel panic if pskb_may_pull() is called on an skb
with a user count greater than one - unfortunately the refactoring did
just that.

Fixing this by removing the skb_get() call and changing the API: The
caller of ipv6_mc_check_mld() / ip_mc_check_igmp() now needs to
additionally check whether the returned skb_trimmed is a clone.

Fixes: 9afd85c9e455 ("net: Export IGMP/MLD message validation code")
Reported-by: Brenden Blanco 
Signed-off-by: Linus Lüssing 
Acked-by: Alexei Starovoitov 
Signed-off-by: David S. Miller

inet: fix possible request socket leak

2015-08-11T04:17:45+00:00

In commit b357a364c57c9 ("inet: fix possible panic in
reqsk_queue_unlink()"), I missed fact that tcp_check_req()
can return the listener socket in one case, and that we must
release the request socket refcount or we leak it.

Tested:

 Following packetdrill test template shows the issue

0     socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
+0    setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
+0    bind(3, ..., ...) = 0
+0    listen(3, 1) = 0

+0    < S 0:0(0) win 2920 
+0    > S. 0:0(0) ack 1 
+.002 < . 1:1(0) ack 21 win 2920
+0    > R 21:21(0)

Fixes: b357a364c57c9 ("inet: fix possible panic in reqsk_queue_unlink()")
Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller

Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf

2015-08-11T04:03:25+00:00

Pablo Neira Ayuso says:

====================
Netfilter fixes for net

The following patchset contains five Netfilter fixes for your net tree,
they are:

1) Silence a warning on falling back to vmalloc(). Since 88eab472ec21, we can
   easily hit this warning message, that gets users confused. So let's get rid
   of it.

2) Recently when porting the template object allocation on top of kmalloc to
   fix the netns dependencies between x_tables and conntrack, the error
   checks where left unchanged. Remove IS_ERR() and check for NULL instead.
   Patch from Dan Carpenter.

3) Don't ignore gfp_flags in the new nf_ct_tmpl_alloc() function, from
   Joe Stringer.

4) Fix a crash due to NULL pointer dereference in ip6t_SYNPROXY, patch from
   Phil Sutter.

5) The sequence number of the Syn+ack that is sent from SYNPROXY to clients is
   not adjusted through our NAT infrastructure, as a result the client may
   ignore this TCP packet and TCP flow hangs until the client probes us.  Also
   from Phil Sutter.
====================

Signed-off-by: David S. Miller

ipv6: don't reject link-local nexthop on other interface

2015-08-10T20:29:22+00:00

48ed7b26faa7 ("ipv6: reject locally assigned nexthop addresses") is too
strict; it rejects following corner-case:

ip -6 route add default via fe80::1:2:3 dev eth1

[ where fe80::1:2:3 is assigned to a local interface, but not eth1 ]

Fix this by restricting search to given device if nh is linklocal.

Joint work with Hannes Frederic Sowa.

Fixes: 48ed7b26faa7 ("ipv6: reject locally assigned nexthop addresses")
Signed-off-by: Hannes Frederic Sowa 
Signed-off-by: Florian Westphal 
Signed-off-by: David S. Miller

netfilter: SYNPROXY: fix sending window update to client

2015-08-10T11:55:07+00:00

Upon receipt of SYNACK from the server, ipt_SYNPROXY first sends back an ACK to
finish the server handshake, then calls nf_ct_seqadj_init() to initiate
sequence number adjustment of forwarded packets to the client and finally sends
a window update to the client to unblock it's TX queue.

Since synproxy_send_client_ack() does not set synproxy_send_tcp()'s nfct
parameter, no sequence number adjustment happens and the client receives the
window update with incorrect sequence number. Depending on client TCP
implementation, this leads to a significant delay (until a window probe is
being sent).

Signed-off-by: Phil Sutter 
Signed-off-by: Pablo Neira Ayuso

netfilter: ip6t_SYNPROXY: fix NULL pointer dereference

2015-08-10T11:54:44+00:00

This happens when networking namespaces are enabled.

Suggested-by: Patrick McHardy 
Signed-off-by: Phil Sutter 
Acked-by: Patrick McHardy 
Signed-off-by: Pablo Neira Ayuso