netdev - Re: [net] bonding: annotate data-races around slave->last

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CANn89iLK1saW=7jxhtew_skR-rPPonFi71brvTApeKM5VVadiA@mail.gmail.com>
Date: Thu, 22 Jan 2026 05:42:55 +0100
From: Eric Dumazet <edumazet@...gle.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: netdev@...r.kernel.org, syzkaller@...glegroups.com, andy@...yhouse.net, 
	eric.dumazet@...il.com, pabeni@...hat.com, j.vosburgh@...il.com, 
	davem@...emloft.net
Subject: Re: [net] bonding: annotate data-races around slave->last_rx

On Thu, Jan 22, 2026 at 3:22 AM Jakub Kicinski <kuba@...nel.org> wrote:
>
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
>
> For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
> ---
> bonding: annotate data-races around slave->last_rx
>
> This patch adds READ_ONCE()/WRITE_ONCE() annotations to slave->last_rx
> and slave->target_last_arp_rx[] to fix KCSAN-reported data races in the
> bonding driver's ARP monitoring code.
>
> > diff --git a/drivers/net/bonding/bond_options.c b/drivers/net/bonding/bond_options.c
> > index 384499c869b8..74708bd2570e 100644
> > --- a/drivers/net/bonding/bond_options.c
> > +++ b/drivers/net/bonding/bond_options.c
> > @@ -1152,7 +1152,7 @@ static void _bond_options_arp_ip_target_set(struct bonding *bond, int slot,
> >
> >       if (slot >= 0 && slot < BOND_MAX_ARP_TARGETS) {
> >               bond_for_each_slave(bond, slave, iter)
> > -                     slave->target_last_arp_rx[slot] = last_rx;
> > +                     WRITE_ONCE(slave->target_last_arp_rx[slot], last_rx);
> >               targets[slot] = target;
> >       }
> >  }
>
> Should the IPv6 NS version of this function also get WRITE_ONCE?
> _bond_options_ns_ip6_target_set() writes to the same target_last_arp_rx[]
> array:
>
>     static void _bond_options_ns_ip6_target_set(...)
>     {
>         ...
>         if (slot >= 0 && slot < BOND_MAX_NS_TARGETS) {
>             bond_for_each_slave(bond, slave, iter) {
>                 slave->target_last_arp_rx[slot] = last_rx;  <-- no WRITE_ONCE
>                 ...
>             }
>         }
>     }
>
> This seems like the same concurrent access pattern that the ARP IPv4 path
> needed fixing for.

I saw this spot, but determined this was used at setup time, not in
packet processing.

I was maybe wrong.