Re: [PATCH v2] atm: lec: fix use-after-free in sock_def_readable()

[Hillf Danton]

On Thu, 12 Mar 2026 06:33:53 +0530 Deepanshu Kartikey wrote:
> On Tue, Mar 10, 2026 at 8:48 AM Hillf Danton <hdanton@xxxxxxxx> wrote:
> >
> > At this point priv->lecd is no longer used, so why not make lecd valid
> > throughout the lifespan of priv and free it after stopping dev queue,
> > instead of the tedious rcu trick?
> >
> 
> Thank you for the suggestion.
> 
> I investigated this approach. While netif_stop_queue() stops
> the TX path and cancel_delayed_work_sync() in lec_arp_destroy()
> stops lec_arp_work, the bug is actually triggered from
> mld_ifc_work (IPv6 multicast workqueue) which calls:
> 
> mld_ifc_work -> mld_sendpack -> ip6_output
>     -> lec_start_xmit -> lec_arp_resolve -> send_to_lecd
> 
> This workqueue belongs to the IPv6 multicast subsystem and
> is completely outside ATM/LEC control. Neither
> netif_stop_queue() nor lec_arp_destroy() can stop it, so
> simply reordering the calls in lec_atm_close() would not
> fix the race.
> 
> The RCU approach with synchronize_rcu() ensures ALL callers
> including mld_ifc_work have finished before priv->lecd is
> cleared.
>
After another look the uaf [1] is due to the race

	vcc_release()		mld_sendpack()
	---			---
				ip6_output()
				__dev_queue_xmit()
				  rcu_read_lock_bh();  // rcu section
				  __dev_xmit_skb()
				  netdev_start_xmit()
				  lec_start_xmit()
				    if (!priv->lecd) {  // check lecd
					kfree_skb(skb);
					return NETDEV_TX_OK;
				    }

	vcc_destroy_socket()
	vcc->dev->ops->close(vcc);
	lec_atm_close()
	  priv->lecd = NULL;	// clear lecd
	  netif_stop_queue(dev);
	sock_put() // free sock

				  lec_arp_resolve()
				  send_to_lecd()
				  sock_def_readable() // uaf

and syncing rcu after clearing lecd is the correct fix because lecd is checked
with rcu lock held.

[1] Subject: [syzbot] [net?] KASAN: slab-use-after-free Read in sock_def_readable (2)
https://lore.kernel.org/all/69ad7ccb.a00a0220.b130.0003.GAE@xxxxxxxxxx/