From: Ido Schimmel <idosch@nvidia.com>
To: Fernando Fernandez Mancera <fmancera@suse.de>
Cc: netdev@vger.kernel.org, linux-kselftest@vger.kernel.org,
horms@kernel.org, pabeni@redhat.com, kuba@kernel.org,
edumazet@google.com, dsahern@kernel.org, davem@davemloft.net,
"Łukasz Stelmach" <steelman@post.pl>
Subject: Re: [PATCH 1/2 net v4] ipv6: addrconf: fix temp address generation after prefix deprecation
Date: Wed, 13 May 2026 17:35:33 +0300 [thread overview]
Message-ID: <20260513143533.GA415119@shredder> (raw)
In-Reply-To: <3f371efe-1b1b-464c-af21-ccd66b6c5df6@suse.de>
On Tue, May 12, 2026 at 08:24:27PM +0200, Fernando Fernandez Mancera wrote:
> Sashiko feedback [1] is right about the DoS, that is a router that sends
> multiple 0-lft RA until it exhausts all spawn attempts, leaving temporary
> addresses disabled on the system.
>
> About the leaked address, I do not think the feedback is right. If an ifp
> does not have any ift, it means something went wrong most likely. Either
> this address was removed manually (any RA would restore it, even with
> previous implementation) or for some reason that prefix didn't get an RA but
> we didn't try to generate one and we MUST do it.
>
> I think we can cover it by avoiding to attempt create a new temporary
> address for a 0-lft RA, it makes sense to me. Something like this:
>
> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> index 18a6f2de30ce..6c511e9c1bf5 100644
> --- a/net/ipv6/addrconf.c
> +++ b/net/ipv6/addrconf.c
> @@ -2654,7 +2654,7 @@ static void manage_tempaddrs(struct inet6_dev *idev,
> * We don't want that to result in creating a new temporary ip address.
> */
> if ((list_empty(&idev->tempaddr_list) || all_regen) &&
> - (valid_lft || prefered_lft))
> + (valid_lft && prefered_lft))
> create = true;
>
> if (create && READ_ONCE(idev->cnf.use_tempaddr) > 0) {
>
> Any thoughts?
This still leaves the case of RAs that alternate between prefered_lft >
0 and prefered_lft == 0. It will cause the kernel to create an unbounded
amount of temporary addresses.
I think that a better fix would be to reset the regeneration counter of
the newest temporary address whenever the associated public address
becomes preferred. Something like [1].
If the newest temporary address has yet to spawn a new address, then its
regeneration counter is 0 and nothing changes. However, if it was
incremented and no new address was created, then this patch will reset
its regeneration counter to reflect that. Before expiring,
addrconf_verify_rtnl() will notice that this address has yet to spawn a
new address and call ipv6_create_tempaddr().
The case of constant RAs with prefered_lft == 0 is not an issue because
we only reset the regeneration counter when prefered_lft > 0.
Alternating RAs are also not an issue because we don't call
ipv6_create_tempaddr() immediately and instead let
addrconf_verify_rtnl() handle it when the address is about to expire.
[1]
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 5476b6536eb7..d550524f4266 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -2595,8 +2595,9 @@ static void manage_tempaddrs(struct inet6_dev *idev,
__u32 valid_lft, __u32 prefered_lft,
bool create, unsigned long now)
{
+ struct inet6_ifaddr *ift, *newest_ift = NULL;
+ u32 orig_prefered_lft = prefered_lft;
u32 flags;
- struct inet6_ifaddr *ift;
read_lock_bh(&idev->lock);
/* update all temporary addresses in the list */
@@ -2606,6 +2607,9 @@ static void manage_tempaddrs(struct inet6_dev *idev,
if (ifp != ift->ifpub)
continue;
+ if (!newest_ift || time_after(ift->cstamp, newest_ift->cstamp))
+ newest_ift = ift;
+
/* RFC 4941 section 3.3:
* If a received option will extend the lifetime of a public
* address, the lifetimes of temporary addresses should
@@ -2643,6 +2647,12 @@ static void manage_tempaddrs(struct inet6_dev *idev,
ipv6_ifa_notify(0, ift);
}
+ if (newest_ift && orig_prefered_lft > 0) {
+ spin_lock(&newest_ift->lock);
+ newest_ift->regen_count = 0;
+ spin_unlock(&newest_ift->lock);
+ }
+
/* Also create a temporary address if it's enabled but no temporary
* address currently exists.
* However, we get called with valid_lft == 0, prefered_lft == 0, create == false
next prev parent reply other threads:[~2026-05-13 14:35 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-11 12:26 [PATCH 1/2 net v4] ipv6: addrconf: fix temp address generation after prefix deprecation Fernando Fernandez Mancera
2026-05-11 12:26 ` [PATCH 2/2 net v4] selftests: fib_tests: add temporary IPv6 address renewal test Fernando Fernandez Mancera
2026-05-11 17:01 ` Breno Leitao
2026-05-12 0:08 ` Jakub Kicinski
2026-05-12 8:08 ` Breno Leitao
2026-05-12 23:56 ` Jakub Kicinski
2026-05-13 8:42 ` Breno Leitao
2026-05-12 18:24 ` [PATCH 1/2 net v4] ipv6: addrconf: fix temp address generation after prefix deprecation Fernando Fernandez Mancera
2026-05-13 14:35 ` Ido Schimmel [this message]
2026-05-14 16:00 ` Fernando Fernandez Mancera
2026-05-15 13:49 ` Ido Schimmel
2026-05-13 0:01 ` Jakub Kicinski
2026-05-13 7:17 ` Ido Schimmel
2026-05-13 7:48 ` Fernando Fernandez Mancera
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260513143533.GA415119@shredder \
--to=idosch@nvidia.com \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=fmancera@suse.de \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=steelman@post.pl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.