linux-toradex.git/net/ipv6/addrconf.c, branch v3.10.56

ipv6: Avoid unnecessary temporary addresses being generated

2014-04-14T13:42:16+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: Greg Kroah-Hartman

IPv6 NAT: Do not drop DNATed 6to4/6rd packets

2013-10-13T23:08:30+00:00

[ Upstream commit 7df37ff33dc122f7bd0614d707939fe84322d264 ]

When a router is doing DNAT for 6to4/6rd packets the latest
anti-spoofing commit 218774dc ("ipv6: add anti-spoofing checks for
6to4 and 6rd") will drop them because the IPv6 address embedded does
not match the IPv4 destination. This patch will allow them to pass by
testing if we have an address that matches on 6to4/6rd interface.  I
have been hit by this problem using Fedora and IPV6TO4_IPV4ADDR.
Also, log the dropped packets (with rate limit).

Signed-off-by: Catalin(ux) M. BOIE 
Acked-by: Hannes Frederic Sowa 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

ipv6: remove max_addresses check from ipv6_create_tempaddr

2013-09-14T13:54:55+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.

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

ipv6,mcast: always hold idev->lock before mca_lock

2013-07-28T23:29:49+00:00

[ Upstream commit 8965779d2c0e6ab246c82a405236b1fb2adae6b2, with
  some bits from commit b7b1bfce0bb68bd8f6e62a28295922785cc63781
  ("ipv6: split duplicate address detection and router solicitation timer")
  to get the __ipv6_get_lladdr() used by this patch. ]

dingtianhong reported the following deadlock detected by lockdep:

 ======================================================
 [ INFO: possible circular locking dependency detected ]
 3.4.24.05-0.1-default #1 Not tainted
 -------------------------------------------------------
 ksoftirqd/0/3 is trying to acquire lock:
  (&ndev->lock){+.+...}, at: [] ipv6_get_lladdr+0x74/0x120

 but task is already holding lock:
  (&mc->mca_lock){+.+...}, at: [] mld_send_report+0x40/0x150

 which lock already depends on the new lock.

 the existing dependency chain (in reverse order) is:

 -> #1 (&mc->mca_lock){+.+...}:
        [] validate_chain+0x637/0x730
        [] __lock_acquire+0x2f7/0x500
        [] lock_acquire+0x114/0x150
        [] rt_spin_lock+0x4a/0x60
        [] igmp6_group_added+0x3b/0x120
        [] ipv6_mc_up+0x38/0x60
        [] ipv6_find_idev+0x3d/0x80
        [] addrconf_notify+0x3d5/0x4b0
        [] notifier_call_chain+0x3f/0x80
        [] raw_notifier_call_chain+0x11/0x20
        [] call_netdevice_notifiers+0x32/0x60
        [] __dev_notify_flags+0x34/0x80
        [] dev_change_flags+0x40/0x70
        [] do_setlink+0x237/0x8a0
        [] rtnl_newlink+0x3ec/0x600
        [] rtnetlink_rcv_msg+0x160/0x310
        [] netlink_rcv_skb+0x89/0xb0
        [] rtnetlink_rcv+0x27/0x40
        [] netlink_unicast+0x140/0x180
        [] netlink_sendmsg+0x33e/0x380
        [] sock_sendmsg+0x112/0x130
        [] __sys_sendmsg+0x44e/0x460
        [] sys_sendmsg+0x44/0x70
        [] system_call_fastpath+0x16/0x1b

 -> #0 (&ndev->lock){+.+...}:
        [] check_prev_add+0x3de/0x440
        [] validate_chain+0x637/0x730
        [] __lock_acquire+0x2f7/0x500
        [] lock_acquire+0x114/0x150
        [] rt_read_lock+0x42/0x60
        [] ipv6_get_lladdr+0x74/0x120
        [] mld_newpack+0xb6/0x160
        [] add_grhead+0xab/0xc0
        [] add_grec+0x3ab/0x460
        [] mld_send_report+0x5a/0x150
        [] igmp6_timer_handler+0x4e/0xb0
        [] call_timer_fn+0xca/0x1d0
        [] run_timer_softirq+0x1df/0x2e0
        [] handle_pending_softirqs+0xf7/0x1f0
        [] __do_softirq_common+0x7b/0xf0
        [] __thread_do_softirq+0x1af/0x210
        [] run_ksoftirqd+0xe1/0x1f0
        [] kthread+0xae/0xc0
        [] kernel_thread_helper+0x4/0x10

actually we can just hold idev->lock before taking pmc->mca_lock,
and avoid taking idev->lock again when iterating idev->addr_list,
since the upper callers of mld_newpack() already take
read_lock_bh(&idev->lock).

Reported-by: dingtianhong 
Cc: dingtianhong 
Cc: Hideaki YOSHIFUJI 
Cc: David S. Miller 
Cc: Hannes Frederic Sowa 
Tested-by: Ding Tianhong 
Tested-by: Chen Weilong 
Signed-off-by: Cong Wang 
Acked-by: Hannes Frederic Sowa 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

ipv6: check return value of ipv6_get_lladdr

2013-06-25T23:27:28+00:00

We should check the return value of ipv6_get_lladdr in inet6_set_iftoken.

A possible situation, which could leave ll_addr unassigned is, when
the user removed her link-local address but a global scoped address was
already set. In this case the interface would still be IF_READY and not
dead. In that case the RS source address is some value from the stack.

v2: Daniel Borkmann noted a small indent inconstancy; no semantic
changes.

Cc: Daniel Borkmann 
Acked-by: Daniel Borkmann 
Reviewed-by: Flavio Leitner 
Signed-off-by: Hannes Frederic Sowa 
Signed-off-by: David S. Miller

ipv6: don't call addrconf_dst_alloc again when enable lo

2013-06-20T06:04:50+00:00

If we disable all of the net interfaces, and enable
un-lo interface before lo interface, we already allocated
the addrconf dst in ipv6_add_addr. So we shouldn't allocate
it again when we enable lo interface.

Otherwise the message below will be triggered.
unregister_netdevice: waiting for sit1 to become free. Usage count = 1

This problem is introduced by commit 25fb6ca4ed9cad72f14f61629b68dc03c0d9713f
"net IPv6 : Fix broken IPv6 routing table after loopback down-up"

Signed-off-by: Gao feng 
Signed-off-by: David S. Miller

ipv6: assign rt6_info to inet6_ifaddr in init_loopback

2013-06-04T23:57:41+00:00

Commit 25fb6ca4ed9cad72f14f61629b68dc03c0d9713f
"net IPv6 : Fix broken IPv6 routing table after loopback down-up"
forgot to assign rt6_info to the inet6_ifaddr.
When disable the net device, the rt6_info which allocated
in init_loopback will not be destroied in __ipv6_ifa_notify.

This will trigger the waring message below
[23527.916091] unregister_netdevice: waiting for tap0 to become free. Usage count = 1

Reported-by: Arkadiusz Miskiewicz 
Signed-off-by: Gao feng 
Signed-off-by: David S. Miller

netfilter: add nf_ipv6_ops hook to fix xt_addrtype with IPv6

2013-05-23T09:58:55+00:00

Quoting https://bugzilla.netfilter.org/show_bug.cgi?id=812:

[ ip6tables -m addrtype ]
When I tried to use in the nat/PREROUTING it messes up the
routing cache even if the rule didn't matched at all.
[..]
If I remove the --limit-iface-in from the non-working scenario, so just
use the -m addrtype --dst-type LOCAL it works!

This happens when LOCAL type matching is requested with --limit-iface-in,
and the default ipv6 route is via the interface the packet we test
arrived on.

Because xt_addrtype uses ip6_route_output, the ipv6 routing implementation
creates an unwanted cached entry, and the packet won't make it to the
real/expected destination.

Silently ignoring --limit-iface-in makes the routing work but it breaks
rule matching (--dst-type LOCAL with limit-iface-in is supposed to only
match if the dst address is configured on the incoming interface;
without --limit-iface-in it will match if the address is reachable
via lo).

The test should call ipv6_chk_addr() instead.  However, this would add
a link-time dependency on ipv6.

There are two possible solutions:

1) Revert the commit that moved ipt_addrtype to xt_addrtype,
   and put ipv6 specific code into ip6t_addrtype.
2) add new "nf_ipv6_ops" struct to register pointers to ipv6 functions.

While the former might seem preferable, Pablo pointed out that there
are more xt modules with link-time dependeny issues regarding ipv6,
so lets go for 2).

Signed-off-by: Florian Westphal 
Signed-off-by: Pablo Neira Ayuso

Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net

2013-04-23T00:32:51+00:00

Conflicts:
	drivers/net/ethernet/emulex/benet/be_main.c
	drivers/net/ethernet/intel/igb/igb_main.c
	drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c
	include/net/scm.h
	net/batman-adv/routing.c
	net/ipv4/tcp_input.c

The e{uid,gid} --> {uid,gid} credentials fix conflicted with the
cleanup in net-next to now pass cred structs around.

The be2net driver had a bug fix in 'net' that overlapped with the VLAN
interface changes by Patrick McHardy in net-next.

An IGB conflict existed because in 'net' the build_skb() support was
reverted, and in 'net-next' there was a comment style fix within that
code.

Several batman-adv conflicts were resolved by making sure that all
calls to batadv_is_my_mac() are changed to have a new bat_priv first
argument.

Eric Dumazet's TS ECR fix in TCP in 'net' conflicted with the F-RTO
rewrite in 'net-next', mostly overlapping changes.

Thanks to Stephen Rothwell and Antonio Quartulli for help with several
of these merge resolutions.

Signed-off-by: David S. Miller

ipv6: statically link register_inet6addr_notifier()

2013-04-14T19:24:17+00:00

Tomas reported the following build error:

net/built-in.o: In function `ieee80211_unregister_hw':
(.text+0x10f0e1): undefined reference to `unregister_inet6addr_notifier'
net/built-in.o: In function `ieee80211_register_hw':
(.text+0x10f610): undefined reference to `register_inet6addr_notifier'
make: *** [vmlinux] Error 1

when built IPv6 as a module.

So we have to statically link these symbols.

Reported-by: Tomas Melin 
Cc: Tomas Melin 
Cc: "David S. Miller" 
Cc: YOSHIFUJI Hidaki 
Signed-off-by: Cong Wang 
Signed-off-by: David S. Miller