linux-kernel - Re: [REGRESSION] net/ipv6/addrconf: Temporary addresses with short lifetimes generating when they shouldn't, causing applications to fail

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]

Message-ID: <CAMMLpeTCZDakqdkxm+jvQHxbRXhCYd4_PK+VVqMAmZHjSPuPRw@mail.gmail.com>
Date: Sat, 23 Dec 2023 17:07:24 -0700
From: Alex Henrie <alexhenrie24@...il.com>
To: Dan Moulding <dan@...m.net>
Cc: bagasdotme@...il.com, davem@...emloft.net, dsahern@...nel.org, 
	edumazet@...gle.com, kuba@...nel.org, linux-kernel@...r.kernel.org, 
	netdev@...r.kernel.org, pabeni@...hat.com, regressions@...ts.linux.dev
Subject: Re: [REGRESSION] net/ipv6/addrconf: Temporary addresses with short
 lifetimes generating when they shouldn't, causing applications to fail

On Sat, Dec 23, 2023 at 8:22 AM Dan Moulding <dan@...m.net> wrote:
>
> > Sorry for the unintended consequences, and thank you for the detailed
> > explanation. Does this patch fix the problem for you?
>
> Thanks. I think this patch may resolve the application-level issues
> I'm seeing.
>
> However, it looks to me like this would still violate the RFC. The
> temoporary address' preferred liftime must be lower than /both/ the
> preferred lifetime of the public address and TEMP_PREFERRED_LIFETIME -
> DESYNC_FACTOR.
>
> These two existing lines ensure that it will meet the requirement:
>
>         cfg.preferred_lft = cnf_temp_preferred_lft + age - idev->desync_factor;
>         cfg.preferred_lft = min_t(__u32, ifp->prefered_lft, cfg.preferred_lft);
>
> Once that has been computed, cfg.preferred_lft is already at its
> maximum allowed value. There is no case where the RFC allows
> increasing that value after doing that computation.

TEMP_PREFERRED_LIFETIME is an administratively set variable: The user
can change it to whatever they want whenever they want, and the
operating system can adjust it automatically too. It might be more
clear to increase cnf_temp_preferred_lft before those two lines, but
the effect is the same as increasing cfg.preferred_lft afterwards.
Unless there's something else I'm missing, I don't see how this
approach could violate the RFC.

> I think the safest thing to do is revert this change, and try to find
> some other way to achieve the goal of preventing the user from
> administratively setting a preferred lifetime that prevents temporary
> addresses from being generated, when the user wants to use the privacy
> extensions. For example, this could be done where administratively
> configured values are accepted (wherever that is), and either generate
> a warning or reject the change, if the value provided by the user is
> lower than REGEN_ADVANCE.

It's fine to revert the commit for version 6.7 (after all, I think
everyone wants a break for the holidays). Hopefully by version 6.8 we
can agree on a way to support users who want to randomize their IPv6
address as frequently as the network allows.

-Alex