[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130120170248.1b168985@lola.kot>
Date: Sun, 20 Jan 2013 17:02:48 +0200
From: George Kargiotakis <kargig@...d.gr>
To: P J P <ppandit@...hat.com>
Cc: oss-security@...ts.openwall.com
Subject: Re: Linux kernel handling of IPv6 temporary
addresses
Hello,
and sorry for the late reply...
On Thu, 17 Jan 2013 18:43:26 +0530 (IST)
P J P <ppandit@...hat.com> wrote:
> +-- On Thu, 17 Jan 2013, George Kargiotakis wrote --+
> | Extensions as far as I know. On your RHEL it's '0' and that's why
> you | weren't seeing any 'ipv6_create_tempaddr' as previously
> mentioned on your | emails. If you change this value to '2' you'll
> also see those kernel | messages.
>
> Yep, worked! I manged to reproduce the log messages. So the patch
> earlier does seem to fix this issue, doesn't it? It avoids retry once
> reaching the max_addresses limit.
>
Yes and no. When flooding finishes everything still works ok,
temp. addresses haven't been disabled, but when the preferred timer
of the temp. address of the original acquired prefix expires, the kernel
won't be able to acquire a new temporary address because the interface
is already full with 16 addresses from flooding. An already acquired
address only gets removed when it's validity timer expires. So, the
host will be left using the global non-temp address acquired by slaac
until another 'slot' (from the default 16) becomes free/expires.
Summarizing, one is still able to remotely, inside a LAN, cause
problems to another host, that is make it lose it's temp. address
functionality at least for some time.
The solution to this problem is not that simple and I've already
referenced a possible solution in one of my previous emails. Maybe a
change of logic from max_addresses per interface to max_prefixes per
interface would help.
> For the dynamic tentative settings of the interface, I think another
> patch would be required.
>
> Thanks so much!
> --
> Prasad J Pandit / Red Hat Security Response Team
> DB7A 84C5 D3F9 7CD1 B5EB C939 D048 7860 3655 602B
Regards,
--
George Kargiotakis
https://void.gr
GPG KeyID: 0xE4F4FFE6
GPG Fingerprint: 9EB8 31BE C618 07CE 1B51 818D 4A0A 1BC8 E4F4 FFE6
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
