[PATCH net v3] ipv6: reject wrapped temporary address preferred lifetimes

[PATCH net v3] ipv6: reject wrapped temporary address preferred lifetimes

[Yingjie Wang]

ipv6_create_tempaddr() raises a temporary address's preferred lifetime to
regen_advance + age + 1 when the configured lifetime is too short. The
result is stored in a u32, while regen_advance and age are unsigned long.
If the sum wraps or is truncated, the stored lifetime can still be less
than or equal to regen_advance + age.

addrconf_verify_rtnl() then sees the new address as due for regeneration
and creates another one. Temporary addresses are not limited by
max_addresses since commit 4b08a8f1bd8c ("ipv6: remove max_addresses
check from ipv6_create_tempaddr"), so this can cause unbounded address
growth. With dad_transmits set to -1, a baseline kernel reached 2859
loopback addresses in two seconds.

After storing the adjusted lifetime, verify that it is still greater than
regen_advance + age. Reject the new address if the check fails.

On an x86-64 KASAN kernel, the normal configuration created three IPv6
addresses. The negative dad_transmits, positive multiplication overflow,
and large retransmission-time cases each left only the loopback and public
addresses. An i386 defconfig and an x86-64 allmodconfig both built
addrconf.o with W=1.

Fixes: f4bcbf360ac8 ("net: ipv6/addrconf: clamp preferred_lft to the minimum required")
Cc: stable@vger.kernel.org
Suggested-by: Ido Schimmel <idosch@nvidia.com>
Link: https://lore.kernel.org/netdev/20261029175827.GA1411453@shredder/
Signed-off-by: Yingjie Wang <1075151112@qq.com>
---
Changes in v3:
- Replace the broad input and arithmetic changes with the post-assignment
  check suggested by Ido Schimmel.
- Preserve the existing sysctl interface and leave the advance calculation,
  desynchronization handling and verification path unchanged.
- Rebase onto net/main at 5838f10563d5 and rerun the focused runtime and
  cross-architecture build checks.

 net/ipv6/addrconf.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index c8c0dd04982d9..d9d13e78bf13b 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -1487,7 +1487,8 @@ static int ipv6_create_tempaddr(struct inet6_ifaddr *ifp, bool block)
 	age = (now - tmp_tstamp + ADDRCONF_TIMER_FUZZ_MINUS) / HZ;
 	if (cfg.preferred_lft <= regen_advance + age) {
 		cfg.preferred_lft = regen_advance + age + 1;
-		if (cfg.preferred_lft > cfg.valid_lft ||
+		if (cfg.preferred_lft <= regen_advance + age ||
+		    cfg.preferred_lft > cfg.valid_lft ||
 		    cfg.preferred_lft > if_public_preferred_lft) {
 			in6_ifa_put(ifp);
 			in6_dev_put(idev);

base-commit: 5838f10563d58afca6711edb5e4eda968ca181d9

Re: [PATCH net v3] ipv6: reject wrapped temporary address preferred lifetimes

[netdev-bot+sinfo]

Hi!

This is an automated message. This series looks like a fix, but its
commit messages seem to be missing some information:

 - How the issue was discovered, e.g. hit in production, hit during
   development, syzbot report, manual code inspection, LLM or static
   analysis tool scan.

Please do not repost the series just to address the above. Instead,
reply to this email with the missing information, so that reviewers
can take it into account. If the series needs another revision for
other reasons, please include the information in the commit messages
then.

The evaluation is done by an LLM so it may be wrong, if you think
that is the case please reply and explain.

Re: [PATCH net v3] ipv6: reject wrapped temporary address preferred lifetimes

[Ido Schimmel]

On Fri, Oct 30, 2026 at 03:30:56PM +0800, Yingjie Wang wrote:
> ipv6_create_tempaddr() raises a temporary address's preferred lifetime to
> regen_advance + age + 1 when the configured lifetime is too short. The
> result is stored in a u32, while regen_advance and age are unsigned long.
> If the sum wraps or is truncated, the stored lifetime can still be less
> than or equal to regen_advance + age.
> 
> addrconf_verify_rtnl() then sees the new address as due for regeneration
> and creates another one. Temporary addresses are not limited by
> max_addresses since commit 4b08a8f1bd8c ("ipv6: remove max_addresses
> check from ipv6_create_tempaddr"), so this can cause unbounded address
> growth. With dad_transmits set to -1, a baseline kernel reached 2859
> loopback addresses in two seconds.
> 
> After storing the adjusted lifetime, verify that it is still greater than
> regen_advance + age. Reject the new address if the check fails.
> 
> On an x86-64 KASAN kernel, the normal configuration created three IPv6
> addresses. The negative dad_transmits, positive multiplication overflow,
> and large retransmission-time cases each left only the loopback and public
> addresses. An i386 defconfig and an x86-64 allmodconfig both built
> addrconf.o with W=1.
> 
> Fixes: f4bcbf360ac8 ("net: ipv6/addrconf: clamp preferred_lft to the minimum required")
> Cc: stable@vger.kernel.org
> Suggested-by: Ido Schimmel <idosch@nvidia.com>
> Link: https://lore.kernel.org/netdev/20261029175827.GA1411453@shredder/
> Signed-off-by: Yingjie Wang <1075151112@qq.com>

Reviewed-by: Ido Schimmel <idosch@nvidia.com>

Re: [PATCH net v3] ipv6: reject wrapped temporary address preferred lifetimes

[Alex Henrie]

On Fri, Oct 30, 2026 at 7:43 AM Ido Schimmel <idosch@nvidia.com> wrote:
>
> On Fri, Oct 30, 2026 at 03:30:56PM +0800, Yingjie Wang wrote:
> > ipv6_create_tempaddr() raises a temporary address's preferred lifetime to
> > regen_advance + age + 1 when the configured lifetime is too short. The
> > result is stored in a u32, while regen_advance and age are unsigned long.
> > If the sum wraps or is truncated, the stored lifetime can still be less
> > than or equal to regen_advance + age.
> >
> > addrconf_verify_rtnl() then sees the new address as due for regeneration
> > and creates another one. Temporary addresses are not limited by
> > max_addresses since commit 4b08a8f1bd8c ("ipv6: remove max_addresses
> > check from ipv6_create_tempaddr"), so this can cause unbounded address
> > growth. With dad_transmits set to -1, a baseline kernel reached 2859
> > loopback addresses in two seconds.
> >
> > After storing the adjusted lifetime, verify that it is still greater than
> > regen_advance + age. Reject the new address if the check fails.
> >
> > On an x86-64 KASAN kernel, the normal configuration created three IPv6
> > addresses. The negative dad_transmits, positive multiplication overflow,
> > and large retransmission-time cases each left only the loopback and public
> > addresses. An i386 defconfig and an x86-64 allmodconfig both built
> > addrconf.o with W=1.
> >
> > Fixes: f4bcbf360ac8 ("net: ipv6/addrconf: clamp preferred_lft to the minimum required")
> > Cc: stable@vger.kernel.org
> > Suggested-by: Ido Schimmel <idosch@nvidia.com>
> > Link: https://lore.kernel.org/netdev/20261029175827.GA1411453@shredder/
> > Signed-off-by: Yingjie Wang <1075151112@qq.com>
>
> Reviewed-by: Ido Schimmel <idosch@nvidia.com>

Reviewed-by: Alex Henrie <alexhenrie24@gmail.com>

Re: [PATCH net v3] ipv6: reject wrapped temporary address preferred lifetimes

[Xia Yan]

Hi,

One question on the clamp added by f4bcbf360ac8, separate from the
wrap fixed here - I don't think this patch needs to address it. I have
only followed the source and have not run this case.

As far as I can tell the clamp's termination relies on cfg.valid_lft
and if_public_preferred_lft being finite. Consider a public address
with both lifetimes at INFINITY_LIFETIME and a large regen_advance,
with no wrap involved. For example with regen_min_advance=2,
regen_max_retry=3, dad_transmits=1, an RA Retrans Timer around
28,600,000 ms and HZ=1000, regen_advance is around 85802; raising
regen_max_retry via sysctl has the same effect.

If temp_prefered_lft is set below regen_advance, the effective
max_desync_factor goes negative, desync_factor is reset to 0, and the
clamp engages on every creation. The clamped preferred lifetime
regen_advance + age + 1 then passes all three checks, including the
new one. But the temporary address inherits the public address's
tstamp, so addrconf_verify_rtnl() finds it due for regeneration one
second after each creation: one new temporary address per second,
each living about temp_valid_lft. Creation is only refused once age
grows enough that regen_advance + age + 1 exceeds cfg.valid_lft,
which here is just temp_valid_lft, so the accumulation is bounded,
but with the numbers above it can still reach tens of thousands of
addresses.

Is this finite-lifetime assumption part of the intended behavior of
the clamp, or would it be worth tightening separately?

Thanks,
Xia

Re: [PATCH net v3] ipv6: reject wrapped temporary address preferred lifetimes

[Yingjie Wang]

Hi Xia,

Agreed, this is separate from the wrapped or truncated lifetime handled
by this patch. In the case you describe, the stored preferred lifetime
does not wrap, so the new check is not intended to reject it.

I have not tested that case or established whether the repeated
regeneration is intended. Thanks for the detailed analysis.

Thanks,
Yingjie

Re: [PATCH net v3] ipv6: reject wrapped temporary address preferred lifetimes

[Alex Henrie]

On Sat, Oct 31, 2026 at 5:44 AM Xia Yan <yanxia@cmss.chinamobile.com> wrote:

> One question on the clamp added by f4bcbf360ac8, separate from the
> wrap fixed here - I don't think this patch needs to address it. I have
> only followed the source and have not run this case.
>
> As far as I can tell the clamp's termination relies on cfg.valid_lft
> and if_public_preferred_lft being finite. Consider a public address
> with both lifetimes at INFINITY_LIFETIME and a large regen_advance,
> with no wrap involved. For example with regen_min_advance=2,
> regen_max_retry=3, dad_transmits=1, an RA Retrans Timer around
> 28,600,000 ms and HZ=1000, regen_advance is around 85802; raising
> regen_max_retry via sysctl has the same effect.
>
> If temp_prefered_lft is set below regen_advance, the effective
> max_desync_factor goes negative, desync_factor is reset to 0, and the
> clamp engages on every creation. The clamped preferred lifetime
> regen_advance + age + 1 then passes all three checks, including the
> new one. But the temporary address inherits the public address's
> tstamp, so addrconf_verify_rtnl() finds it due for regeneration one
> second after each creation: one new temporary address per second,
> each living about temp_valid_lft. Creation is only refused once age
> grows enough that regen_advance + age + 1 exceeds cfg.valid_lft,
> which here is just temp_valid_lft, so the accumulation is bounded,
> but with the numbers above it can still reach tens of thousands of
> addresses.
>
> Is this finite-lifetime assumption part of the intended behavior of
> the clamp, or would it be worth tightening separately?

Hello Xia, that is a good question. In that extreme scenario, creating
one temporary address per second is intentional. As you noted,
regen_advance is not a constant. Before I added the clamp, Linux would
just stop creating temporary addresses if regen_advance increased to a
value larger than the preferred lifetime that the user specified. No
new addresses were created until the network interface was restarted,
even if later on regen_advance dropped to below the user's preferred
lifetime. Temporary address generation was effectively disabled,
eliminating the privacy protections that the user thought that they
had enabled.

When I wrote the patch, I did not consider that the temporary
addresses might be based on a static address that has an infinite
lifetime. If having a static address causes Linux to refuse to create
more temporary addresses after a certain period of time, that's a bug.
However, I have not been able to reproduce the problem: On my machine,
with a static address, max_desync_factor=10, temp_prefered_lft=30,
regen_min_advance=60, and temp_valid_lft=90, Linux 7.2 never stops
creating new temporary addresses. Is there another combination of
parameters that might cause a problem?

-Alex

Re: [PATCH net v3] ipv6: reject wrapped temporary address preferred lifetimes

[Xia Yan]

On 11/1/26 22:08, Alex Henrie wrote:
> Is there another combination of parameters that might cause a problem?

Hi Alex,

Thanks for explaining the reasoning behind the clamp. I was wrong
about creation eventually being refused as the public address gets
older. I had missed the "+ age" in cfg.valid_lft.

With an infinite-lifetime parent, cfg.valid_lft grows with age too.
For the values you tested, I don't see an age-dependent cutoff in
that lifetime check. Normal successful regenerations don't reach the
retry limit either: addrconf_verify_rtnl() resets the parent's
regen_count before each regeneration. Repeated ipv6_add_addr() or DAD
failures can still exhaust the retries.

I don't have a reproducer for another refusal case.

The remaining worry for me is retention. With a short preferred
lifetime and temp_valid_lft at its two-day default, deprecated
temporary addresses stay on the interface until their valid lifetime
expires, and this path does not check max_addresses. Your 90-second
configuration ages them out fast; with the default I would expect
many more addresses held at once, but I have not tested that or
measured the cost. The creation rate also depends on DAD timing, so
my earlier one-address-per-second estimate was too definite.

Thanks,
Xia

Re: [PATCH net v3] ipv6: reject wrapped temporary address preferred lifetimes

[patchwork-bot+netdevbpf]

Hello:

This patch was applied to netdev/net.git (main)
by Paolo Abeni <pabeni@redhat.com>:

On Fri, 30 Oct 2026 15:30:56 +0800 you wrote:
> ipv6_create_tempaddr() raises a temporary address's preferred lifetime to
> regen_advance + age + 1 when the configured lifetime is too short. The
> result is stored in a u32, while regen_advance and age are unsigned long.
> If the sum wraps or is truncated, the stored lifetime can still be less
> than or equal to regen_advance + age.
> 
> addrconf_verify_rtnl() then sees the new address as due for regeneration
> and creates another one. Temporary addresses are not limited by
> max_addresses since commit 4b08a8f1bd8c ("ipv6: remove max_addresses
> check from ipv6_create_tempaddr"), so this can cause unbounded address
> growth. With dad_transmits set to -1, a baseline kernel reached 2859
> loopback addresses in two seconds.
> 
> [...]

Here is the summary with links:
  - [net,v3] ipv6: reject wrapped temporary address preferred lifetimes
    https://git.kernel.org/netdev/net/c/c3e67bd82b9b

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html