On Mon, Mar 9, 2026 at 10:55 AM Eric Dumazet [off-list ref] wrote:

On Mon, Mar 9, 2026 at 10:36 AM Deepanshu Kartikey
[off-list ref] wrote:

quoted

A race condition exists between lec_atm_close() setting priv->lecd = NULL
and concurrent access to priv->lecd in send_to_lecd(), lec_handle_bridge(),
and lec_atm_send(). When the socket is freed via RCU while another thread
is still using it, a use-after-free occurs in sock_def_readable() when
accessing the socket's wait queue.

The root cause is that lec_atm_close() clears priv->lecd without holding
lec_arp_lock, while callers dereference priv->lecd without any protection
against concurrent teardown.

Fix this by:
- Protecting priv->lecd = NULL in lec_atm_close() with lec_arp_lock to
  synchronize with callers that already hold the lock (e.g. lec_arp_resolve)
- Using sock_hold/sock_put in send_to_lecd() to pin the socket while in
  use. This is safe because send_to_lecd() is called under lec_arp_lock
  by lec_arp_resolve(), preventing concurrent NULL assignment of lecd.
- Using lec_arp_lock + sock_hold/sock_put in lec_handle_bridge() and
  lec_atm_send() where the lock is not held by the caller, with proper
  skb cleanup on early exit to avoid memory leaks.

Note: Patch testing via syzbot was attempted but the test VM crashed
due to a QEMU AHCI emulation assertion failure (hw/ide/core.c:934)
unrelated to this fix. The QEMU crash is caused by syzbot's disk I/O
fuzzing triggering a known QEMU NCQ emulation bug, not by this patch.
Compile testing with "make W=1 net/atm/lec.o" passes cleanly.

Reported-by: syzbot+f50072212ab792c86925@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=f50072212ab792c86925
Signed-off-by: Deepanshu Kartikey <redacted>
---
 net/atm/lec.c | 31 +++++++++++++++++++++++++++----
 1 file changed, 27 insertions(+), 4 deletions(-)

diff --git a/net/atm/lec.c b/net/atm/lec.c
index fb93c6e1c329..7e051174a92b 100644
--- a/net/atm/lec.c
+++ b/net/atm/lec.c

@@ -131,6 +131,7 @@ static void lec_handle_bridge(struct sk_buff *skb, struct net_device *dev)
 {
        char *buff;
        struct lec_priv *priv;
+       unsigned long flags;

        /*
         * Check if this is a BPDU. If so, ask zeppelin to send

@@ -154,10 +155,19 @@ static void lec_handle_bridge(struct sk_buff *skb, struct net_device *dev)
                                        /* 0x01 is topology change */

                priv = netdev_priv(dev);
-               atm_force_charge(priv->lecd, skb2->truesize);
+               spin_lock_irqsave(&priv->lec_arp_lock, flags);
+               if (!priv->lecd) {
+                       spin_unlock_irqrestore(&priv->lec_arp_lock, flags);
+                       kfree_skb(skb2);
+                       return;
+               }
                sk = sk_atm(priv->lecd);
+               sock_hold(sk);
+               spin_unlock_irqrestore(&priv->lec_arp_lock, flags);

What prevents priv->lecd to be NULL after you released priv->lec_arp_lock ?

More generally, lec_atm_close() clears the sk_receive_queue.

So allowing providers to queue more packets would be wrong.

So really a better fix is needed.