All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ido Schimmel <idosch@nvidia.com>
To: Linkui Xiao <xiaolinkui@126.com>
Cc: dsahern@kernel.org, davem@davemloft.net, edumazet@google.com,
	kuba@kernel.org, pabeni@redhat.com, horms@kernel.org,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	Linkui Xiao <xiaolinkui@kylinos.cn>
Subject: Re: [PATCH net v2] ipv4: fib: fix data-race and stale genid check around nh->nh_saddr
Date: Tue, 15 Sep 2026 20:53:54 +0300	[thread overview]
Message-ID: <20260915175354.GA805835@shredder> (raw)
In-Reply-To: <20260915071503.465875-1-xiaolinkui@126.com>

On Tue, Sep 15, 2026 at 03:15:03PM +0800, Linkui Xiao wrote:
> From: Linkui Xiao <xiaolinkui@kylinos.cn>
> 
> fib_select_multipath() compares nexthop_nh->nh_saddr against the flow
> source address with no lock held, while fib_info_update_nhc_saddr()
> stores a new value from another CPU as soon as the preferred source
> address of the egress device changes.
> 
> Commit 195374d89368 ("ipv4: fib: annotate races around nh->nh_saddr_genid
> and nh->nh_saddr") added WRITE_ONCE() on the store side and READ_ONCE()
> in fib_result_prefsrc() after syzbot reported
> 
> 	BUG: KCSAN: data-race in fib_select_path / fib_select_path
> 
> but it only covered that reader. fib_select_multipath(), reached from
> fib_select_path(), is a second lockless reader of nh->nh_saddr and was
> left bare.
> 
> Moreover, nh_saddr is only meaningful when nh_saddr_genid matches
> dev_addr_genid, as established by 195374d89368. fib_select_multipath()

It's established by commit 436c3b66ec98 ("ipv4: Invalidate nexthop cache
nh_saddr more correctly.")

> skips that validation, so it can score a nexthop using a stale source
> address and skew the ECMP selection.
> 
> Annotate both reads with READ_ONCE() and add the missing genid check,
> mirroring fib_result_prefsrc().
> 
> Fixes: 32607a332cfe ("ipv4: prefer multipath nexthop that matches source address")
> Signed-off-by: Linkui Xiao <xiaolinkui@kylinos.cn>
> ---
> V1: https://lore.kernel.org/all/CANn89iJhFL2LNQCXTANQAx8B1GVdGTJgrDwPTZOjbH8k1ygtsg@mail.gmail.com/
> 
> V2:
> - point Fixes: at 32607a332cfe, which introduced the bare reader
> - add the missing genid check as suggested by Eric Dumazet
> 
>  net/ipv4/fib_semantics.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/net/ipv4/fib_semantics.c b/net/ipv4/fib_semantics.c
> index 7a362f2e2c2b..e2bfc11aea09 100644
> --- a/net/ipv4/fib_semantics.c
> +++ b/net/ipv4/fib_semantics.c
> @@ -2184,6 +2184,7 @@ void fib_select_multipath(struct fib_result *res, int hash,
>  	bool use_neigh;
>  	int score = -1;
>  	__be32 saddr;
> +	int genid;
>  
>  	if (unlikely(res->fi->nh)) {
>  		nexthop_path_fib_result(res, hash);
> @@ -2192,6 +2193,7 @@ void fib_select_multipath(struct fib_result *res, int hash,
>  
>  	use_neigh = READ_ONCE(net->ipv4.sysctl_fib_multipath_use_neigh);
>  	saddr = fl4 ? fl4->saddr : 0;
> +	genid = saddr ? atomic_read(&net->ipv4.dev_addr_genid) : 0;
>  
>  	change_nexthops(fi) {
>  		int nh_upper_bound, nh_score = 0;
> @@ -2204,7 +2206,9 @@ void fib_select_multipath(struct fib_result *res, int hash,
>  		    (use_neigh && !fib_good_nh(nexthop_nh)))
>  			continue;
>  
> -		if (saddr && nexthop_nh->nh_saddr == saddr)
> +		if (saddr &&
> +		    READ_ONCE(nexthop_nh->nh_saddr_genid) == genid &&
> +		    READ_ONCE(nexthop_nh->nh_saddr) == saddr)
>  			nh_score += 2;
>  		if (hash <= nh_upper_bound)
>  			nh_score++;

The cached generation ID can remain stale for a long time and during
this time we will silently downgrade the nexthop selection to be hash
based. We need to refresh it in case there is a mismatch. Something
like:

diff --git a/net/ipv4/fib_semantics.c b/net/ipv4/fib_semantics.c
index e2bfc11aea09..5c9021ea3a79 100644
--- a/net/ipv4/fib_semantics.c
+++ b/net/ipv4/fib_semantics.c
@@ -2176,6 +2176,15 @@ static bool fib_good_nh(const struct fib_nh *nh)
 	return !!(state & NUD_VALID);
 }
 
+static __be32 fib_nh_saddr(struct net *net, const struct fib_info *fi,
+			   struct fib_nh *nh, int genid)
+{
+	if (READ_ONCE(nh->nh_saddr_genid) == genid)
+		return READ_ONCE(nh->nh_saddr);
+
+	return fib_info_update_nhc_saddr(net, &nh->nh_common, fi->fib_scope);
+}
+
 void fib_select_multipath(struct fib_result *res, int hash,
 			  const struct flowi4 *fl4)
 {
@@ -2206,9 +2215,7 @@ void fib_select_multipath(struct fib_result *res, int hash,
 		    (use_neigh && !fib_good_nh(nexthop_nh)))
 			continue;
 
-		if (saddr &&
-		    READ_ONCE(nexthop_nh->nh_saddr_genid) == genid &&
-		    READ_ONCE(nexthop_nh->nh_saddr) == saddr)
+		if (saddr && fib_nh_saddr(net, fi, nexthop_nh, genid) == saddr)
 			nh_score += 2;
 		if (hash <= nh_upper_bound)
 			nh_score++;


  reply	other threads:[~2026-09-15 17:54 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-15  7:15 [PATCH net v2] ipv4: fib: fix data-race and stale genid check around nh->nh_saddr Linkui Xiao
2026-09-15 17:53 ` Ido Schimmel [this message]
2026-09-16  2:15   ` Linkui Xiao
2026-09-17  7:18 ` netdev-bot+sashiko

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=20260915175354.GA805835@shredder \
    --to=idosch@nvidia.com \
    --cc=davem@davemloft.net \
    --cc=dsahern@kernel.org \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=xiaolinkui@126.com \
    --cc=xiaolinkui@kylinos.cn \
    /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.