linux-stable.git/net/ipv6, branch v3.16.6

ip6_gre: fix flowi6_proto value in xmit path

2014-10-15T10:05:29+00:00

[ Upstream commit 3be07244b7337760a3269d56b2f4a63e72218648 ]

In xmit path, we build a flowi6 which will be used for the output route lookup.
We are sending a GRE packet, neither IPv4 nor IPv6 encapsulated packet, thus the
protocol should be IPPROTO_GRE.

Fixes: c12b395a4664 ("gre: Support GRE over IPv6")
Reported-by: Matthieu Ternisien d'Ouville 
Signed-off-by: Nicolas Dichtel 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

ipv6: remove rt6i_genid

2014-10-15T10:05:29+00:00

[ Upstream commit 705f1c869d577c8055736dd02501f26a2507dd5b ]

Eric Dumazet noticed that all no-nonexthop or no-gateway routes which
are already marked DST_HOST (e.g. input routes routes) will always be
invalidated during sk_dst_check. Thus per-socket dst caching absolutely
had no effect and early demuxing had no effect.

Thus this patch removes rt6i_genid: fn_sernum already gets modified during
add operations, so we only must ensure we mutate fn_sernum during ipv6
address remove operations. This is a fairly cost extensive operations,
but address removal should not happen that often. Also our mtu update
functions do the same and we heard no complains so far. xfrm policy
changes also cause a call into fib6_flush_trees. Also plug a hole in
rt6_info (no cacheline changes).

I verified via tracing that this change has effect.

Cc: Eric Dumazet 
Cc: YOSHIFUJI Hideaki 
Cc: Vlad Yasevich 
Cc: Nicolas Dichtel 
Cc: Martin Lau 
Signed-off-by: Hannes Frederic Sowa 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

xfrm: Generate blackhole routes only from route lookup functions

2014-10-15T10:05:29+00:00

[ Upstream commit f92ee61982d6da15a9e49664ecd6405a15a2ee56 ]

Currently we genarate a blackhole route route whenever we have
matching policies but can not resolve the states. Here we assume
that dst_output() is called to kill the balckholed packets.
Unfortunately this assumption is not true in all cases, so
it is possible that these packets leave the system unwanted.

We fix this by generating blackhole routes only from the
route lookup functions, here we can guarantee a call to
dst_output() afterwards.

Fixes: 2774c131b1d ("xfrm: Handle blackhole route creation via afinfo.")
Reported-by: Konstantinos Kolelis 
Signed-off-by: Steffen Klassert 
Signed-off-by: Greg Kroah-Hartman

ipv6: restore the behavior of ipv6_sock_ac_drop()

2014-10-15T10:05:28+00:00

[ Upstream commit de185ab46cb02df9738b0d898b0c3a89181c5526 ]

It is possible that the interface is already gone after joining
the list of anycast on this interface as we don't hold a refcount
for the device, in this case we are safe to ignore the error.

What's more important, for API compatibility we should not
change this behavior for applications even if it were correct.

Fixes: commit a9ed4a2986e13011 ("ipv6: fix rtnl locking in setsockopt for anycast and multicast")
Cc: Sabrina Dubroca 
Cc: David S. Miller 
Signed-off-by: Cong Wang 
Acked-by: Hannes Frederic Sowa 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

ipv6: fix rtnl locking in setsockopt for anycast and multicast

2014-10-15T10:05:28+00:00

[ Upstream commit a9ed4a2986e13011fcf4ed2d1a1647c53112f55b ]

Calling setsockopt with IPV6_JOIN_ANYCAST or IPV6_LEAVE_ANYCAST
triggers the assertion in addrconf_join_solict()/addrconf_leave_solict()

ipv6_sock_ac_join(), ipv6_sock_ac_drop(), ipv6_sock_ac_close() need to
take RTNL before calling ipv6_dev_ac_inc/dec. Same thing with
ipv6_sock_mc_join(), ipv6_sock_mc_drop(), ipv6_sock_mc_close() before
calling ipv6_dev_mc_inc/dec.

This patch moves ASSERT_RTNL() up a level in the call stack.

Signed-off-by: Cong Wang 
Signed-off-by: Sabrina Dubroca 
Reported-by: Tommi Rantala 
Acked-by: Hannes Frederic Sowa 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: ipv6: fib: don't sleep inside atomic lock

2014-10-15T10:05:27+00:00

[ Upstream commit 793c3b4000a1ef611ae7e5c89bd2a9c6b776cb5e ]

The function fib6_commit_metrics() allocates a piece of memory in mode
GFP_KERNEL while holding an atomic lock from higher up in the stack, in
the function __ip6_ins_rt(). This produces the following BUG:

> BUG: sleeping function called from invalid context at mm/slub.c:1250
> in_atomic(): 1, irqs_disabled(): 0, pid: 2909, name: dhcpcd
> 2 locks held by dhcpcd/2909:
>  #0:  (rtnl_mutex){+.+.+.}, at: [] rtnl_lock+0x17/0x20
>  #1:  (&tb->tb6_lock){++--+.}, at: [] ip6_route_add+0x65a/0x800
> CPU: 1 PID: 2909 Comm: dhcpcd Not tainted 3.17.0-rc1 #1
> Hardware name: ASUS All Series/Q87T, BIOS 0216 10/16/2013
>  0000000000000008 ffff8800c8f13858 ffffffff81af135a 0000000000000000
>  ffff880212202430 ffff8800c8f13878 ffffffff810f8d3a ffff880212202c98
>  0000000000000010 ffff8800c8f138c8 ffffffff8121ad0e 0000000000000001
> Call Trace:
>  [] dump_stack+0x4e/0x68
>  [] __might_sleep+0x10a/0x120
>  [] kmem_cache_alloc_trace+0x4e/0x190
>  [] ? fib6_commit_metrics+0x66/0x110
>  [] fib6_commit_metrics+0x66/0x110
>  [] fib6_add+0x883/0xa80
>  [] ? ip6_route_add+0x65a/0x800
>  [] ip6_route_add+0x675/0x800
>  [] ? ip6_route_add+0x6a/0x800
>  [] inet6_rtm_newroute+0x5c/0x80
>  [] rtnetlink_rcv_msg+0x211/0x260
>  [] ? rtnl_lock+0x17/0x20
>  [] ? lock_release_holdtime+0x28/0x180
>  [] ? rtnl_lock+0x17/0x20
>  [] ? __rtnl_unlock+0x20/0x20
>  [] netlink_rcv_skb+0x6e/0xd0
>  [] rtnetlink_rcv+0x25/0x40
>  [] netlink_unicast+0xd9/0x180
>  [] netlink_sendmsg+0x700/0x770
>  [] ? local_clock+0x25/0x30
>  [] sock_sendmsg+0x6c/0x90
>  [] ? might_fault+0xa3/0xb0
>  [] ? verify_iovec+0x7d/0xf0
>  [] ___sys_sendmsg+0x37e/0x3b0
>  [] ? trace_hardirqs_on_caller+0x185/0x220
>  [] ? mutex_unlock+0xe/0x10
>  [] ? netlink_insert+0xbc/0xe0
>  [] ? netlink_autobind.isra.30+0x125/0x150
>  [] ? netlink_autobind.isra.30+0x60/0x150
>  [] ? netlink_bind+0x159/0x230
>  [] ? might_fault+0x5a/0xb0
>  [] ? SYSC_bind+0x7e/0xd0
>  [] __sys_sendmsg+0x4d/0x80
>  [] SyS_sendmsg+0x12/0x20
>  [] system_call_fastpath+0x16/0x1b

Fixing this by replacing the mode GFP_KERNEL with GFP_ATOMIC.

Signed-off-by: Benjamin Block 
Acked-by: David Rientjes 
Acked-by: Hannes Frederic Sowa 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

tcp: fix tcp_release_cb() to dispatch via address family for mtu_reduced()

2014-10-15T10:05:27+00:00

[ Upstream commit 4fab9071950c2021d846e18351e0f46a1cffd67b ]

Make sure we use the correct address-family-specific function for
handling MTU reductions from within tcp_release_cb().

Previously AF_INET6 sockets were incorrectly always using the IPv6
code path when sometimes they were handling IPv4 traffic and thus had
an IPv4 dst.

Signed-off-by: Neal Cardwell 
Signed-off-by: Eric Dumazet 
Diagnosed-by: Willem de Bruijn 
Fixes: 563d34d057862 ("tcp: dont drop MTU reduction indications")
Reviewed-by: Hannes Frederic Sowa 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

sit: Fix ipip6_tunnel_lookup device matching criteria

2014-10-15T10:05:27+00:00

[ Upstream commit bc8fc7b8f825ef17a0fb9e68c18ce94fa66ab337 ]

As of 4fddbf5d78 ("sit: strictly restrict incoming traffic to tunnel link device"),
when looking up a tunnel, tunnel's underlying interface (t->parms.link)
is verified to match incoming traffic's ingress device.

However the comparison was incorrectly based on skb->dev->iflink.

Instead, dev->ifindex should be used, which correctly represents the
interface from which the IP stack hands the ipip6 packets.

This allows setting up sit tunnels bound to vlan interfaces (otherwise
incoming ipip6 traffic on the vlan interface was dropped due to
ipip6_tunnel_lookup match failure).

Signed-off-by: Shmulik Ladkani 
Acked-by: Nicolas Dichtel 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

ip: make IP identifiers less predictable

2014-07-29T01:46:34+00:00

In "Counting Packets Sent Between Arbitrary Internet Hosts", Jeffrey and
Jedidiah describe ways exploiting linux IP identifier generation to
infer whether two machines are exchanging packets.

With commit 73f156a6e8c1 ("inetpeer: get rid of ip_id_count"), we
changed IP id generation, but this does not really prevent this
side-channel technique.

This patch adds a random amount of perturbation so that IP identifiers
for a given destination [1] are no longer monotonically increasing after
an idle period.

Note that prandom_u32_max(1) returns 0, so if generator is used at most
once per jiffy, this patch inserts no hole in the ID suite and do not
increase collision probability.

This is jiffies based, so in the worst case (HZ=1000), the id can
rollover after ~65 seconds of idle time, which should be fine.

We also change the hash used in __ip_select_ident() to not only hash
on daddr, but also saddr and protocol, so that ICMP probes can not be
used to infer information for other protocols.

For IPv6, adds saddr into the hash as well, but not nexthdr.

If I ping the patched target, we can see ID are now hard to predict.

21:57:11.008086 IP (...)
    A > target: ICMP echo request, seq 1, length 64
21:57:11.010752 IP (... id 2081 ...)
    target > A: ICMP echo reply, seq 1, length 64

21:57:12.013133 IP (...)
    A > target: ICMP echo request, seq 2, length 64
21:57:12.015737 IP (... id 3039 ...)
    target > A: ICMP echo reply, seq 2, length 64

21:57:13.016580 IP (...)
    A > target: ICMP echo request, seq 3, length 64
21:57:13.019251 IP (... id 3437 ...)
    target > A: ICMP echo reply, seq 3, length 64

[1] TCP sessions uses a per flow ID generator not changed by this patch.

Signed-off-by: Eric Dumazet 
Reported-by: Jeffrey Knockel 
Reported-by: Jedidiah R. Crandall 
Cc: Willy Tarreau 
Cc: Hannes Frederic Sowa 
Signed-off-by: David S. Miller

net-gre-gro: Fix a bug that breaks the forwarding path

2014-07-16T21:45:26+00:00

Fixed a bug that was introduced by my GRE-GRO patch
(bf5a755f5e9186406bbf50f4087100af5bd68e40 net-gre-gro: Add GRE
support to the GRO stack) that breaks the forwarding path
because various GSO related fields were not set. The bug will
cause on the egress path either the GSO code to fail, or a
GRE-TSO capable (NETIF_F_GSO_GRE) NICs to choke. The following
fix has been tested for both cases.

Signed-off-by: H.K. Jerry Chu 
Signed-off-by: David S. Miller