Re: [PATCH bpf v1 1/2] net/bpf: fix null-ptr-deref in xdp_master_redirect() for bonding

["Jiayuan Chen" <jiayuan.chen@linux.dev>]

2026/2/26 17:58, "Sebastian Andrzej Siewior" <bigeasy@linutronix.de mailto:bigeasy@linutronix.de?to=%22Sebastian%20Andrzej%20Siewior%22%20%3Cbigeasy%40linutronix.de%3E > wrote:


> 
> On 2026-02-24 19:25:41 [+0800], Jiayuan Chen wrote:
> 
> > 
> > --- a/net/core/filter.c
> >  +++ b/net/core/filter.c
> >  @@ -4387,6 +4387,9 @@ u32 xdp_master_redirect(struct xdp_buff *xdp)
> >  struct net_device *master, *slave;
> >  
> >  master = netdev_master_upper_dev_get_rcu(xdp->rxq->dev);
> >  + if (unlikely(!master || !netif_running(master)))
> >  + return XDP_TX;
> >  +
> > 
> I'm not sure this check belongs here as this is not bond specific, is
> it? Also nothing stops the admin to put the device right after the
> netif_running() check so it fails later but the race window is not as
> wide as it is now.
> 
> The per-CPU memory could be allocated while the bond device is created.
> I don't think delaying it until "device up" brings any advantages.
> One creates the device with the intention to use it so the "up" is
> inevitable.
> The bond_xmit_get_slave() callback has the same logic. Couldn't this
> scenario also occur to the ->ndo_get_xmit_slave() user?
> 
> > 
> > slave = master->netdev_ops->ndo_xdp_get_xmit_slave(master, xdp);
> >  if (slave && slave != xdp->rxq->dev) {
> >  /* The target device is different from the receiving device, so
> > 
> Sebastian
>

I agree with your points, especially allocating
rr_tx_counter unconditionally at device creation time in bond_setup().

This eliminates the NULL possibility from the root, fixes both the
ndo_xdp_get_xmit_slave and ndo_get_xmit_slave paths, and keeps the
change within the bonding subsystem.

I'll wait a bit to collect more feedback before sending a v2.