Re: [PATCHv2 net] bonding: alb: fix UAF in rlb_arp_recv during bond up/down

[Hangbin Liu <liuhangbin@gmail.com>]

On Wed, Feb 18, 2026 at 04:11:10PM -0800, Jakub Kicinski wrote:
> On Wed, 18 Feb 2026 04:36:24 +0000 Hangbin Liu wrote:
> > On Tue, Feb 17, 2026 at 04:43:55PM -0800, Jakub Kicinski wrote:
> > > On Sat, 14 Feb 2026 09:15:41 +0000 Hangbin Liu wrote:  
> > > > Fixes: e53665c6eaa6 ("bonding: delete migrated IP addresses from the rlb hash table")  
> > > 
> > > Ah, also AI says the issue existed already in 
> > > 3aba891dde38 ("bonding: move processing of recv handlers into
> > > handle_frame()")
> > > not the exact trapping instruction but the hash table was used from
> > > recv_probe so at least a UAF would happen.  
> > 
> > Not sure if I understand correctly. Do you mean we still able to access
> > rlb_arp_recv() after setting recv_probe to NULL?
> 
> Simply put -- wasn't there a case where rx_hashtbl was accessed after
> being freed in 3aba891dde38 already? That commit is a year and a half
> older than the commit you had under Fixes.

AFAIK, the UAF/null-ptr-deref issue for rx_hashtble is introduced by
53665c6eaa6 ("bonding: delete migrated IP addresses from the rlb hash table"),
which added rlb_purge_src_ip() in rlb_arp_recv().

In 3aba891dde38 ("bonding: move processing of recv handlers into handle_frame()")
it only let other CPU still able to access rlb_arp_recv() after we set recv_probe
to NULL. But it doesn't trigger a null-ptr-deref.

Thanks
Hangbin