netdev - Re: Regression in IPv6 autoconf, maybe "ipv6/addrconf: fix timing bug in tempaddr regen"

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] [thread-next>] [day] [month] [year] [list]

Date: Wed, 31 May 2023 10:31:33 -0600
From: Sam Edwards <cfsworks@...il.com>
To: Jan Engelhardt <jengelh@...i.de>
Cc: Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org,
 "David S. Miller" <davem@...emloft.net>
Subject: Re: Regression in IPv6 autoconf, maybe "ipv6/addrconf: fix timing bug
 in tempaddr regen"

Hey there Jan,

On 5/31/23 03:20, Jan Engelhardt wrote:
> Greetings.
> 
> I am observing that between kernel 5.19 and 6.0, a change was introduced
> that makes the system just stop generating IPv6 Privacy Addresses after
> some time.

I'd been encountering this exact problem very reliably since at least 
the early 4.x days, which was my motivation for authoring this patch 
(which had fully fixed the problem for me).

So imagine my surprise to learn that not only did the patch not 
completely resolve the issue, and that the problem doesn't happen 
reliably enough for you on the earlier kernels to see it in your 
regression test, but that my patch is evidently making the problem 
happen *more* frequently in your case!

You're probably right to single this commit out of your shortlog, since 
it is directly related to this problem, but just to be sure: could you 
skip the bisecting ahead to test this commit vs. its parent?

I'm going to be very confused if this change is definitely to blame. 
Before this change, the problem happened because there was a narrow time 
window for temporary address regeneration, where addrconf_verify_rtnl() 
had to run right before the previous temporary address was about to run 
out its preferred lifetime, but before it actually did so. This patch 
ought not to be doing anything more than removing the requirement that 
the old address is still preferred, so it should make the problem happen 
less often (if at all) -- not more.

Since we're having some pretty extreme Works On My Machine Syndrome 
here, we should really figure out what's different in your case from 
mine. What arch are you building these kernels for? Could you share the 
defconfig? Are you able to see this on multiple machines/networks or 
have you only tried the one? Is this machine real hardware or a VM?

Kind regards,
Sam