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

[Hangbin Liu <liuhangbin@gmail.com>]

On Thu, Feb 19, 2026 at 01:34:10PM +0000, Hangbin Liu wrote:
> 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.

Oh, I remember now. rlb_arp_recv() also calls rlb_update_entry_from_arp(),
which could access rx_hashtbl. You are right, the fixes tag should be
3aba891dde38 ("bonding: move processing of recv handlers into handle_frame()")

Thanks
Hangbin