oss-sec mailing list archives

Re: Linux kernel handling of IPv6 temporary addresses


From: P J P <ppandit () redhat com>
Date: Wed, 16 Jan 2013 23:40:16 +0530 (IST)


  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


Current thread: