netdev - Re: [IPv6 Question] Should we remove or keep the temporary address if global address removed?

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: <ZyrI07Dq_YRWFk6A@fedora>
Date: Wed, 6 Nov 2024 01:39:31 +0000
From: Hangbin Liu <liuhangbin@...il.com>
To: Sam Edwards <cfsworks@...il.com>
Cc: netdev@...r.kernel.org
Subject: Re: [IPv6 Question] Should we remove or keep the temporary address
 if global address removed?

Hi Sam,
On Tue, Nov 05, 2024 at 04:50:46PM -0800, Sam Edwards wrote:
> > After checking the code, it looks commit 778964f2fdf0 ("ipv6/addrconf: fix
> > timing bug in tempaddr regen") changes the behavior. I can't find what we should
> > do when delete the related global address from RFC8981. So I'm not sure
> > which way we should do. Keep or delete the temporary address.
> >
> > Do you have any idea?
> 
> Hi Hangbin,
> 
> RFC8981 section 3.4 does say that existing temporary addresses must
> have their lifetimes adjusted so that no temporary addresses should
> ever remain "valid" or "preferred" longer than the incoming SLAAC
> Prefix Information. This would strongly imply in Linux's case that if
> the "mngtmpaddr" address is deleted or un-flagged as such, its
> corresponding temporary addresses must be cleared out right away. That
> also makes intuitive sense to me, because if an administrator is
> deleting (or un-flagging) "mngtmpaddr" they very likely want no more
> temporary addresses within that prefix.

Thanks for the confirmation.

> 
> So, I would say what you've found is a bug. Doubly so because the
> temporaries contain a pointer to the managing address, which is
> possibly now dangling.
> 
> By the way, I don't think my patch from 2 years ago is still working
> correctly: I'm seeing that my (high-uptime) workstation has two
> mngtmpaddr addresses, one public address and one internal to my LAN,
> but currently only the "internal to my LAN" one has any
> still-preferred temporary addresses currently.
> 
> Last time around, Paolo strongly suggested that I include a regression
> test with my patch. I now realize it's a good idea to write such a
> test:
> 1. Create a dummy Ethernet interface, with temp_*_lft configured to be
> pretty short (10 and 35 seconds for prefer/valid respectively?)
> 2. Create several (3-4) mngtmpaddr addresses on that interface.
> 3. Confirm that temporary addresses are created immediately.
> 4. Confirm that a preferred temporary address exists for each
> mngtmpaddr address at all times, polling once per second for at least
> 10 minutes.
> 5. Delete each mngtmpaddr address, one at a time (alternating between
> deleting and merely un-mngtmpaddr-ing), and confirm that the other
> mngtmpaddr addresses still have preferred temporaries.
> 6. Within steps 3-5, also confirm that any temporaries that exist have
> a corresponding mngtmpaddr. (Basically the test should, at all steps,
> confirm that every existing mngtmpaddr has at least one preferred
> temporary, and that every existing temporary has a matching
> mngtmpaddr.)
> 
> This test should fail, demonstrating both of these bugs, when run
> against the latest kernel. Then we can get to work on making the test
> pass.
> 
> Are you interested in writing that test or should I? I have never
> contributed test cases to the kernel before, so there'd be a bit of a
> learning curve for me, but I'm happy to do it.

I can write the test and maybe also the fixes. But it could take at least 2
weeks as I also have some other works in hand. If you can do it more quick,
please feel free to do it first.

Thanks
Hangbin