Re: [PATCH 1/2 net-next v2] ipv6: clear RA flags when adding a static route

[David Ahern <dsahern@kernel.org>]

On 11/15/25 2:59 AM, Fernando Fernandez Mancera wrote:
> When an IPv6 Router Advertisement (RA) is received for a prefix, the
> kernel creates the corresponding on-link route with flags RTF_ADDRCONF
> and RTF_PREFIX_RT configured and RTF_EXPIRES if lifetime is set.
> 
> If later a user configures a static IPv6 address on the same prefix the
> kernel clears the RTF_EXPIRES flag but it doesn't clear the RTF_ADDRCONF
> and RTF_PREFIX_RT. When the next RA for that prefix is received, the
> kernel sees the route as RA-learned and wrongly configures back the
> lifetime. This is problematic because if the route expires, the static
> address won't have the corresponding on-link route.
> 
> This fix clears the RTF_ADDRCONF and RTF_PREFIX_RT flags preventing that
> the lifetime is configured when the next RA arrives. If the static
> address is deleted, the route becomes RA-learned again.
> 
> Fixes: 14ef37b6d00e ("ipv6: fix route lookup in addrconf_prefix_rcv()")
> Reported-by: Garri Djavadyan <g.djavadyan@gmail.com>
> Closes: https://lore.kernel.org/netdev/ba807d39aca5b4dcf395cc11dca61a130a52cfd3.camel@gmail.com/
> Signed-off-by: Fernando Fernandez Mancera <fmancera@suse.de>
> ---
> v2: rebase in top of net-next.git instead of net.git
> ---
>  net/ipv6/ip6_fib.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/net/ipv6/ip6_fib.c b/net/ipv6/ip6_fib.c
> index 02c16909f618..2111af022d94 100644
> --- a/net/ipv6/ip6_fib.c
> +++ b/net/ipv6/ip6_fib.c
> @@ -1138,6 +1138,10 @@ static int fib6_add_rt2node(struct fib6_node *fn, struct fib6_info *rt,
>  					fib6_set_expires(iter, rt->expires);
>  					fib6_add_gc_list(iter);
>  				}
> +				if (!(rt->fib6_flags & (RTF_ADDRCONF | RTF_PREFIX_RT))) {
> +					iter->fib6_flags &= ~RTF_ADDRCONF;
> +					iter->fib6_flags &= ~RTF_PREFIX_RT;
> +				}
>  
>  				if (rt->fib6_pmtu)
>  					fib6_metric_set(iter, RTAX_MTU,

Converting an RA route to a static route should be a very rare use case.
I can't find a reason why this is wrong, so:

Reviewed-by: David Ahern <dsahern@kernel.org>