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 for Android: free password hash cracker in your pocket

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

Message-ID: <20231223152235.15713-1-dan@danm.net>
Date: Sat, 23 Dec 2023 08:22:35 -0700
From: Dan Moulding <dan@...m.net>
To: alexhenrie24@...il.com
Cc: bagasdotme@...il.com,
	dan@...m.net,
	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

> 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.

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.

-- Dan