On 3/10/26 1:39 PM, Nikolay Aleksandrov wrote: > On Tue, Mar 10, 2026 at 01:07:15PM +0100, Eric Dumazet wrote: >> 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. > > IIRC when the redirect continues, the packet should get dropped if the device > is > not up (checks at a few places), but that's outside of bond's jurisdiction and > after the slave id is needed in xdp master redirect's path unfortunately. > I'm not sure it can reach much further, it just has the master dev's slave id > generation in its path. > > In any case we shouldn't crash in the slave id generation in the bonding, > that ndo's only job is to return a slave id.
I'm sorry for the back and forth, but I share Eric's concern. I think the approach suggested by Daniel: https://lore.kernel.org/netdev/[email protected]/ or the initial patch form: https://lore.kernel.org/netdev/[email protected]/T/#m7c67bb12f85bc88d583788fb6e41113c46208ae7 would be better. To respond to old concerns raised there: the check is IMHO bond-specific, as control moves from the lower interface to the upper bonding device, and the code is under an RCU critical section, the device can't go away before the xmit is completed. /P
