From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-kernel@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
stable@vger.kernel.org,
Hannes Frederic Sowa <hannes@stressinduktion.org>,
Ding Tianhong <dingtianhong@huawei.com>,
George Kargiotakis <kargig@void.gr>, P J P <ppandit@redhat.com>,
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>,
"David S. Miller" <davem@davemloft.net>
Subject: [ 08/19] ipv6: remove max_addresses check from ipv6_create_tempaddr
Date: Thu, 12 Sep 2013 10:26:17 -0700 [thread overview]
Message-ID: <20130912172525.076734923@linuxfoundation.org> (raw)
In-Reply-To: <20130912172524.135620246@linuxfoundation.org>
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
[ Upstream commit 4b08a8f1bd8cb4541c93ec170027b4d0782dab52 ]
Because of the max_addresses check attackers were able to disable privacy
extensions on an interface by creating enough autoconfigured addresses:
<http://seclists.org/oss-sec/2012/q4/292>
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 <hannes@stressinduktion.org>
Cc: Ding Tianhong <dingtianhong@huawei.com>
Cc: George Kargiotakis <kargig@void.gr>
Cc: P J P <ppandit@redhat.com>
Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Acked-by: Ding Tianhong <dingtianhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/ipv6/addrconf.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -912,12 +912,10 @@ retry:
if (ifp->flags & IFA_F_OPTIMISTIC)
addr_flags |= IFA_F_OPTIMISTIC;
- ift = !max_addresses ||
- ipv6_count_addresses(idev) < max_addresses ?
- ipv6_add_addr(idev, &addr, tmp_plen,
- ipv6_addr_type(&addr)&IPV6_ADDR_SCOPE_MASK,
- addr_flags) : NULL;
- if (!ift || IS_ERR(ift)) {
+ ift = ipv6_add_addr(idev, &addr, tmp_plen,
+ ipv6_addr_type(&addr)&IPV6_ADDR_SCOPE_MASK,
+ addr_flags);
+ if (IS_ERR(ift)) {
in6_ifa_put(ifp);
in6_dev_put(idev);
printk(KERN_INFO
next prev parent reply other threads:[~2013-09-12 17:26 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-12 17:26 [ 00/19] 3.0.96-stable review Greg Kroah-Hartman
2013-09-12 17:26 ` [ 01/19] htb: fix sign extension bug Greg Kroah-Hartman
2013-09-12 17:26 ` [ 02/19] net: check net.core.somaxconn sysctl values Greg Kroah-Hartman
2013-09-12 17:26 ` [ 03/19] fib_trie: remove potential out of bound access Greg Kroah-Hartman
2013-09-12 17:26 ` [ 04/19] tcp: cubic: fix overflow error in bictcp_update() Greg Kroah-Hartman
2013-09-12 17:26 ` [ 05/19] tcp: cubic: fix bug in bictcp_acked() Greg Kroah-Hartman
2013-09-12 17:26 ` [ 06/19] ipv6: dont stop backtracking in fib6_lookup_1 if subtree does not match Greg Kroah-Hartman
2013-09-12 17:26 ` [ 07/19] tun: signedness bug in tun_get_user() Greg Kroah-Hartman
2013-09-12 17:26 ` Greg Kroah-Hartman [this message]
2013-09-12 17:26 ` [ 09/19] ipv6: drop packets with multiple fragmentation headers Greg Kroah-Hartman
2013-09-12 17:26 ` [ 10/19] ipv6: Dont depend on per socket memory for neighbour discovery messages Greg Kroah-Hartman
2013-09-12 17:26 ` [ 11/19] net: bridge: convert MLDv2 Query MRC into msecs_to_jiffies for max_delay Greg Kroah-Hartman
2013-09-12 17:26 ` [ 12/19] ICMPv6: treat dest unreachable codes 5 and 6 as EACCES, not EPROTO Greg Kroah-Hartman
2013-09-12 17:26 ` [ 13/19] tipc: fix lockdep warning during bearer initialization Greg Kroah-Hartman
2013-09-12 17:26 ` [ 14/19] PARISC: include <linux/prefetch.h> in drivers/parisc/iommu-helpers.h Greg Kroah-Hartman
2013-09-12 17:26 ` [ 15/19] pci: frv architecture needs generic setup-bus infrastructure Greg Kroah-Hartman
2013-09-12 17:26 ` [ 16/19] m32r: consistently use "suffix-$(...)" Greg Kroah-Hartman
2013-09-12 17:26 ` [ 17/19] m32r: add memcpy() for CONFIG_KERNEL_GZIP=y Greg Kroah-Hartman
2013-09-12 17:26 ` [ 18/19] m32r: make memset() global for CONFIG_KERNEL_BZIP2=y Greg Kroah-Hartman
2013-09-12 17:26 ` [ 19/19] KVM: s390: move kvm_guest_enter,exit closer to sie Greg Kroah-Hartman
2013-09-12 22:29 ` [ 00/19] 3.0.96-stable review Guenter Roeck
2013-09-12 23:07 ` Greg Kroah-Hartman
2013-09-13 23:04 ` Shuah Khan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130912172525.076734923@linuxfoundation.org \
--to=gregkh@linuxfoundation.org \
--cc=davem@davemloft.net \
--cc=dingtianhong@huawei.com \
--cc=hannes@stressinduktion.org \
--cc=kargig@void.gr \
--cc=linux-kernel@vger.kernel.org \
--cc=ppandit@redhat.com \
--cc=stable@vger.kernel.org \
--cc=yoshfuji@linux-ipv6.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).