|
Message-ID: <alpine.LFD.2.03.1301162315300.8305@erqung.pbz> Date: Wed, 16 Jan 2013 23:40:16 +0530 (IST) From: P J P <ppandit@...hat.com> To: oss-security@...ts.openwall.com cc: kargig@...d.gr Subject: Re: Linux kernel handling of IPv6 temporary addresses Hello George, +-- On Wed, 16 Jan 2013, George Kargiotakis wrote --+ | what distro/kernel version are you trying ? I'm using latest ubuntu 12.10 with 3.5.7. | The messages I'm mentioning certainly appear upon testing with ubuntu 12.10 live CD for example. I'm using RHEL-6.3 with kernel-2.6.32. | Your new patch works "better", but still the main problem hasn't been | eliminated. And I explain myself. | | While flooding with RAs the following appears in the dmesg: | [ 117.721878] IPv6: ipv6_create_tempaddr: ipv6 temporary address upper limit reached | | which is what your patch is supposed to do. But acquired addresses | from flooding all seem to have the tentative flag on: | inet6 fd00:966f:7996:c731:9191:a3ce:99bc:897e/64 scope global temporary tentative dynamic Yes, I too observed similar output, not sure it's because of the patch though. I guess problem is somewhere else, I'm looking. | what I also find wrong here is that all temporary addresses (dynamic) | acquired have gotten the same last 64bits. I don't think this is OK per RFC | 4941 even if not explicitly defined there. Every temp. address created | should be different per prefix from the rest. | | use_tempaddr for the iface still has '2' as its value | # cat /proc/sys/net/ipv6/conf/eth0/use_tempaddr | 2 | | then after taking the interface down and up again even the new addresses acquired still have the tentative flag enabled: | | dmesg reports: | [ 322.195426] IPv6: ipv6_create_tempaddr: regeneration time exceeded - disabled temporary address support | | use_tempaddr for the iface now has '-1' as its value though | # cat /proc/sys/net/ipv6/conf/eth0/use_tempaddr | -1 | | And so there actually isn't any IPv6 connectivity from then on until a reboot. | Flooding triggers something that corrupts ipv6 functionality. I see, I'll try to look for these clues, will get back asap. Thanks so much. -- Prasad J Pandit / Red Hat Security Response Team DB7A 84C5 D3F9 7CD1 B5EB C939 D048 7860 3655 602B
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.