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);
