netdev - Re: possible bug in IPv6 MLD retransmissions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20130623141802.GA13836@order.stressinduktion.org>
Date:	Sun, 23 Jun 2013 16:18:02 +0200
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	David Stevens <dlstevens@...ibm.com>,
	David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
	netdev-owner@...r.kernel.org,
	Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>
Subject: Re: possible bug in IPv6 MLD retransmissions

On Thu, May 23, 2013 at 10:21:56PM +0200, Hannes Frederic Sowa wrote:
> On Wed, May 22, 2013 at 07:30:39AM -0400, David Stevens wrote:
> > Second, I think doing this on all LL addresses unconditionally isn't a 
> > good
> > idea. If some configuration is using thousands of LL addrs for reasons of 
> > their
> > own, they would suddenly be blasted with unexpected MLD reports where
> > they have none now. I don't see why tracking it would be such a problem --
> > if nothing else, you could simply add a counter for the number of valid LL 
> > addrs
> > incremented on DAD completion, and send these whenever it transitions from 
> > 0 to 1.
> 
> While testing some code, I noticed that we seem to have a similar
> problem with the generation of router soliciations. We send out
> MAX_RTR_SOLICITATIONS for each link-local address dad completion.
> 
> So the tracking could have some more users and I will move it to
> addrconf.c. I'll hope I cope with all the tiny races I found in my last
> version. :)

Sorry, I could not finish this patch before I got distracted with other
things. I had a look at it again yesterday and came up with the following
plan:

a) split up router advertisment and dad timer
b) remove src-argument from ndisc_send_rs and calculate it from the ll
   addresses of the interface when sending the RS
c) introduce ll_dad_completion counter
d) rebase the above patch onto this utilising the ll_dad_completion counter

Does this plan sound solid?

I plan to send out a patch for a) today.

Greetings,

  Hannes

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html