On Tue, Mar 10, 2026 at 1:00 PM Eric Dumazet <[email protected]> wrote: > > On Tue, Mar 10, 2026 at 12:49 PM Nikolay Aleksandrov > <[email protected]> wrote: > > > > On Mon, Mar 09, 2026 at 11:06:58AM +0800, Jiayuan Chen wrote: > > > From: Jiayuan Chen <[email protected]> > > > > > > bond_rr_gen_slave_id() dereferences bond->rr_tx_counter without a NULL > > > check. rr_tx_counter is a per-CPU counter only allocated in bond_open() > > > when the bond mode is round-robin. If the bond device was never brought > > > up, rr_tx_counter remains NULL, causing a null-ptr-deref. > > > > > > The XDP redirect path can reach this code even when the bond is not up: > > > bpf_master_redirect_enabled_key is a global static key, so when any bond > > > device has native XDP attached, the XDP_TX -> xdp_master_redirect() > > > interception is enabled for all bond slaves system-wide. This allows the > > > path xdp_master_redirect() -> bond_xdp_get_xmit_slave() -> > > > bond_xdp_xmit_roundrobin_slave_get() -> bond_rr_gen_slave_id() to be > > > reached on a bond that was never opened. > > > > > > Fix this by adding a NULL check with unlikely() in bond_rr_gen_slave_id() > > > before dereferencing rr_tx_counter. When rr_tx_counter is NULL (bond was > > > never opened), fall back to get_random_u32() for slave selection. The > > > allocation in bond_open() is kept, with WRITE_ONCE() added to safely > > > publish the pointer to the XDP read side. A plain read suffices for the > > > !bond->rr_tx_counter guard in bond_open() itself, as bond_open() runs > > > under RTNL lock and is the only writer of rr_tx_counter. > > > > > > Fixes: 879af96ffd72 ("net, core: Add support for XDP redirection to slave > > > device") > > > Reported-by: [email protected] > > > Closes: > > > https://lore.kernel.org/all/[email protected]/T/ > > > Signed-off-by: Jiayuan Chen <[email protected]> > > > --- > > > drivers/net/bonding/bond_main.c | 9 +++++++-- > > > 1 file changed, 7 insertions(+), 2 deletions(-) > > > > > > > This is Jay's patch + the unlikely change, looks good to me. > > Reviewed-by: Nikolay Aleksandrov <[email protected]> > > Orthogonal to this patch : > > get_random_u32() typical cost is around 10 to 20 ns, I really wonder > if this makes sense > for the packets_per_slave == 0 or 1 case to haves this kind of > randomness in the first place. > > Perhaps we could use a > > static DEFINE_PER_CPU(u32, rr_tx_counter) > > And : > slave_id = this_cpu_inc_return(rr_tx_counter);
I also have mixed feelings about this patch. We probably should detect that the device is not ready before hitting something deeper in the stack. Sure, a NULL deref is avoided, bu what happens next ? We send a packet while the device is not UP, I am pretty sure this violates at least some RCU rules in device dismantling.
