linux-stable.git/net/ipv6/addrconf.c, branch linux-3.2.y

ipv6: fix sparse warning on rt6i_node

2017-11-11T13:34:35+00:00

commit 4e587ea71bf924f7dac621f1351653bd41e446cb upstream.

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 
[bwh: Backported to 3.2:
 - fib6_add_rt2node() has only one assignment to update
 - Drop changes in rt6_cache_allowed_for_pmtu()
 - Adjust context]
Signed-off-by: Ben Hutchings

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

2017-10-12T14:27:13+00:00

commit ec8add2a4c9df723c94a863b8fcd6d93c472deed upstream.

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 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

ipv6: always add flag an address that failed DAD with DADFAILED

2017-10-12T14:27:13+00:00

commit 3d171f3907329d4b1ce31d5ec9c852c5f0269578 upstream.

The userspace needs to know why is the address being removed so that it can
perhaps obtain a new address.

Without the DADFAILED flag it's impossible to distinguish removal of a
temporary and tentative address due to DAD failure from other reasons (device
removed, manual address removal).

Signed-off-by: Lubomir Rintel 
Acked-by: Hannes Frederic Sowa 
Signed-off-by: David S. Miller 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

ipv6: avoid unregistering inet6_dev for loopback

2017-09-15T17:30:55+00:00

commit 60abc0be96e00ca71bac083215ac91ad2e575096 upstream.

The per netns loopback_dev->ip6_ptr is unregistered and set to
NULL when its mtu is set to smaller than IPV6_MIN_MTU, this
leads to that we could set rt->rt6i_idev NULL after a
rt6_uncached_list_flush_dev() and then crash after another
call.

In this case we should just bring its inet6_dev down, rather
than unregistering it, at least prior to commit 176c39af29bc
("netns: fix addrconf_ifdown kernel panic") we always
override the case for loopback.

Thanks a lot to Andrey for finding a reliable reproducer.

Fixes: 176c39af29bc ("netns: fix addrconf_ifdown kernel panic")
Reported-by: Andrey Konovalov 
Cc: Andrey Konovalov 
Cc: Daniel Lezcano 
Cc: David Ahern 
Signed-off-by: Cong Wang 
Acked-by: David Ahern 
Tested-by: Andrey Konovalov 
Signed-off-by: David S. Miller 
[bwh: Backported to 3.2: the NETDEV_CHANGEMTU case used to fall-through to the
 NETDEV_DOWN case here, so replace that with a separate call to addrconf_ifdown()]
Signed-off-by: Ben Hutchings

ipv6: addrconf: Avoid addrconf_disable_change() using RCU read-side lock

2017-03-16T02:18:56+00:00

[ Upstream commit 03e4deff4987f79c34112c5ba4eb195d4f9382b0 ]

Just like commit 4acd4945cd1e ("ipv6: addrconf: Avoid calling
netdevice notifiers with RCU read-side lock"), it is unnecessary
to make addrconf_disable_change() use RCU iteration over the
netdev list, since it already holds the RTNL lock, or we may meet
Illegal context switch in RCU read-side critical section.

Signed-off-by: Kefeng Wang 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

net/ipv6: add sysctl option accept_ra_min_hop_limit

2016-04-30T22:05:25+00:00

[ Upstream commit 8013d1d7eafb0589ca766db6b74026f76b7f5cb4 ]

Commit 6fd99094de2b ("ipv6: Don't reduce hop limit for an interface")
disabled accept hop limit from RA if it is smaller than the current hop
limit for security stuff. But this behavior kind of break the RFC definition.

RFC 4861, 6.3.4.  Processing Received Router Advertisements
   A Router Advertisement field (e.g., Cur Hop Limit, Reachable Time,
   and Retrans Timer) may contain a value denoting that it is
   unspecified.  In such cases, the parameter should be ignored and the
   host should continue using whatever value it is already using.

   If the received Cur Hop Limit value is non-zero, the host SHOULD set
   its CurHopLimit variable to the received value.

So add sysctl option accept_ra_min_hop_limit to let user choose the minimum
hop limit value they can accept from RA. And set default to 1 to meet RFC
standards.

Signed-off-by: Hangbin Liu 
Acked-by: YOSHIFUJI Hideaki 
Signed-off-by: David S. Miller 
[bwh: Backported to 3.2:
 - Adjust filename, context
 - Number DEVCONF enumerators explicitly to match upstream]
Signed-off-by: Ben Hutchings

ipv6: addrconf: validate new MTU before applying it

2015-10-13T02:46:11+00:00

commit 77751427a1ff25b27d47a4c36b12c3c8667855ac upstream.

Currently we don't check if the new MTU is valid or not and this allows
one to configure a smaller than minimum allowed by RFCs or even bigger
than interface own MTU, which is a problem as it may lead to packet
drops.

If you have a daemon like NetworkManager running, this may be exploited
by remote attackers by forging RA packets with an invalid MTU, possibly
leading to a DoS. (NetworkManager currently only validates for values
too small, but not for too big ones.)

The fix is just to make sure the new value is valid. That is, between
IPV6_MIN_MTU and interface's MTU.

Note that similar check is already performed at
ndisc_router_discovery(), for when kernel itself parses the RA.

Signed-off-by: Marcelo Ricardo Leitner 
Signed-off-by: Sabrina Dubroca 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

ipv6: reallocate addrconf router for ipv6 address when lo device up

2014-11-05T20:27:47+00:00

It fix the bug 67951 on bugzilla
https://bugzilla.kernel.org/show_bug.cgi?id=67951

The patch can't be applied directly, as it' used the function introduced
by "commit 94e187c0" ip6_rt_put(), that patch can't be applied directly
either.

====================

From: Gao feng 

commit 33d99113b1102c2d2f8603b9ba72d89d915c13f5 upstream.

This commit don't have a stable tag, but it fix the bug
no reply after loopback down-up.It's very worthy to be
applied to stable 3.4 kernels.

The bug is 67951 on bugzilla
https://bugzilla.kernel.org/show_bug.cgi?id=67951


CC: Sabrina Dubroca 
CC: Hannes Frederic Sowa 
Reported-by: Weilong Chen 
Signed-off-by: Weilong Chen 
Signed-off-by: Gao feng 
Acked-by: Hannes Frederic Sowa 
Signed-off-by: David S. Miller 
[weilong: s/ip6_rt_put/dst_release]
Signed-off-by: Chen Weilong 
Signed-off-by: Ben Hutchings

ipv6: Avoid unnecessary temporary addresses being generated

2014-04-30T15:23:17+00:00

[ Upstream commit ecab67015ef6e3f3635551dcc9971cf363cc1cd5 ]

tmp_prefered_lft is an offset to ifp->tstamp, not now. Therefore
age needs to be added to the condition.

Age calculation in ipv6_create_tempaddr is different from the one
in addrconf_verify and doesn't consider ADDRCONF_TIMER_FUZZ_MINUS.
This can cause age in ipv6_create_tempaddr to be less than the one
in addrconf_verify and therefore unnecessary temporary address to
be generated.
Use age calculation as in addrconf_modify to avoid this.

Signed-off-by: Heiner Kallweit 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

ipv6: remove max_addresses check from ipv6_create_tempaddr

2013-10-26T20:05:56+00:00

[ Upstream commit 4b08a8f1bd8cb4541c93ec170027b4d0782dab52 ]

Because of the max_addresses check attackers were able to disable privacy
extensions on an interface by creating enough autoconfigured addresses:



But the check is not actually needed: max_addresses protects the
kernel to install too many ipv6 addresses on an interface and guards
addrconf_prefix_rcv to install further addresses as soon as this limit
is reached. We only generate temporary addresses in direct response of
a new address showing up. As soon as we filled up the maximum number of
addresses of an interface, we stop installing more addresses and thus
also stop generating more temp addresses.

Even if the attacker tries to generate a lot of temporary addresses
by announcing a prefix and removing it again (lifetime == 0) we won't
install more temp addresses, because the temporary addresses do count
to the maximum number of addresses, thus we would stop installing new
autoconfigured addresses when the limit is reached.

This patch fixes CVE-2013-0343 (but other layer-2 attacks are still
possible).

Thanks to Ding Tianhong to bring this topic up again.

Cc: Ding Tianhong 
Cc: George Kargiotakis 
Cc: P J P 
Cc: YOSHIFUJI Hideaki 
Signed-off-by: Hannes Frederic Sowa 
Acked-by: Ding Tianhong 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings