[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <094aedc7-3303-7f27-25eb-a32523faa5b7@gmail.com>
Date: Thu, 7 Nov 2019 09:37:07 -0700
From: David Ahern <dsahern@...il.com>
To: Eric Dumazet <edumazet@...gle.com>,
"David S . Miller" <davem@...emloft.net>
Cc: netdev <netdev@...r.kernel.org>,
Eric Dumazet <eric.dumazet@...il.com>,
syzbot <syzkaller@...glegroups.com>
Subject: Re: [PATCH net] ipv6: fixes rt6_probe() and fib6_nh->last_probe init
On 11/6/19 7:45 PM, Eric Dumazet wrote:
> While looking at a syzbot KCSAN report [1], I found multiple
> issues in this code :
>
> 1) fib6_nh->last_probe has an initial value of 0.
>
> While probably okay on 64bit kernels, this causes an issue
> on 32bit kernels since the time_after(jiffies, 0 + interval)
> might be false ~24 days after boot (for HZ=1000)
>
> 2) The data-race found by KCSAN
> I could use READ_ONCE() and WRITE_ONCE(), but we also can
> take the opportunity of not piling-up too many rt6_probe_deferred()
> works by using instead cmpxchg() so that only one cpu wins the race.
>
...
> Fixes: cc3a86c802f0 ("ipv6: Change rt6_probe to take a fib6_nh")
That commit only moves the location of last_probe, from fib6_info into
fib6_nh. Given that I would expect the same problem to exist with the
previous code. Agree? Point being should this be backported to older
stable releases since said commit is new to 5.2?
Powered by blists - more mailing lists