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.