From: "Jiayuan Chen" <jiayuan.chen@linux.dev>
To: "Dan Carpenter" <dan.carpenter@linaro.org>
Cc: netdev@vger.kernel.org, "Jiayuan Chen" <jiayuan.chen@shopee.com>,
syzbot+72e3ea390c305de0e259@syzkaller.appspotmail.com,
"David S. Miller" <davem@davemloft.net>,
"Eric Dumazet" <edumazet@google.com>,
"Jakub Kicinski" <kuba@kernel.org>,
"Paolo Abeni" <pabeni@redhat.com>,
"Simon Horman" <horms@kernel.org>,
"Ingo Molnar" <mingo@kernel.org>,
"Thomas Gleixner" <tglx@kernel.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH net v1] atm: lec: fix null-ptr-deref in lec_arp_clear_vccs
Date: Wed, 25 Feb 2026 11:32:52 +0000 [thread overview]
Message-ID: <6bc6f7fe686e53fe2aaca467920ccf300546d5bf@linux.dev> (raw)
In-Reply-To: <aZ7V5b5ZplD4B9i1@stanley.mountain>
February 25, 2026 at 18:58, "Dan Carpenter" <dan.carpenter@linaro.org mailto:dan.carpenter@linaro.org?to=%22Dan%20Carpenter%22%20%3Cdan.carpenter%40linaro.org%3E > wrote:
>
> On Tue, Feb 24, 2026 at 12:46:38PM +0800, Jiayuan Chen wrote:
>
> >
> > From: Jiayuan Chen <jiayuan.chen@shopee.com>
> >
> > syzkaller reported a null-ptr-deref in lec_arp_clear_vccs().
> > This issue can be easily reproduced using the syzkaller reproducer.
> >
> > In the ATM LANE (LAN Emulation) module, the same atm_vcc can be shared by
> > multiple lec_arp_table entries (e.g., via entry->vcc or entry->recv_vcc).
> > When the underlying VCC is closed, lec_vcc_close() iterates over all
> > ARP entries and calls lec_arp_clear_vccs() for each matched entry.
> >
> > For example, when lec_vcc_close() iterates through the hlists in
> > priv->lec_arp_empty_ones or other ARP tables:
> >
> > 1. In the first iteration, for the first matched ARP entry sharing the VCC,
> > lec_arp_clear_vccs() frees the associated vpriv (which is vcc->user_back)
> > and sets vcc->user_back to NULL.
> > 2. In the second iteration, for the next matched ARP entry sharing the same
> > VCC, lec_arp_clear_vccs() is called again. It obtains a NULL vpriv from
> > vcc->user_back (via LEC_VCC_PRIV(vcc)) and then attempts to dereference it
> > via `vcc->pop = vpriv->old_pop`, leading to a null-ptr-deref crash.
> >
> > Fix this by adding a null check for vpriv before dereferencing it. If
> > vpriv is already NULL, it means the VCC has been cleared by a previous
> > call, so we can safely skip the cleanup and just clear the entry's
> > vcc/recv_vcc pointers. Note that the added check is intentional and
> > necessary to avoid calling vcc_release_async() multiple times on the
> > same vcc/recv_vcc, not just protecting the kfree().
> >
> > Reported-by: syzbot+72e3ea390c305de0e259@syzkaller.appspotmail.com
> > Closes: https://lore.kernel.org/all/68c95a83.050a0220.3c6139.0e5c.GAE@google.com/T/
> > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> > Signed-off-by: Jiayuan Chen <jiayuan.chen@shopee.com>
> > ---
> > net/atm/lec.c | 27 +++++++++++++++------------
> > 1 file changed, 15 insertions(+), 12 deletions(-)
> >
> > diff --git a/net/atm/lec.c b/net/atm/lec.c
> > index afb8d3eb2185..a5b80d6df603 100644
> > --- a/net/atm/lec.c
> > +++ b/net/atm/lec.c
> > @@ -1260,24 +1260,27 @@ static void lec_arp_clear_vccs(struct lec_arp_table *entry)
> > struct lec_vcc_priv *vpriv = LEC_VCC_PRIV(vcc);
> > struct net_device *dev = (struct net_device *)vcc->proto_data;
> >
> > - vcc->pop = vpriv->old_pop;
> > - if (vpriv->xoff)
> > - netif_wake_queue(dev);
> > - kfree(vpriv);
> > - vcc->user_back = NULL;
> > - vcc->push = entry->old_push;
> > - vcc_release_async(vcc, -EPIPE);
> > + if (vpriv) {
> > + vcc->pop = vpriv->old_pop;
> > + if (vpriv->xoff)
> > + netif_wake_queue(dev);
> > + kfree(vpriv);
> > + vcc->user_back = NULL;
> > + vcc->push = entry->old_push;
> > + vcc_release_async(vcc, -EPIPE);
> > + }
> > entry->vcc = NULL;
> > }
> > if (entry->recv_vcc) {
> > struct atm_vcc *vcc = entry->recv_vcc;
> > struct lec_vcc_priv *vpriv = LEC_VCC_PRIV(vcc);
> >
> > - kfree(vpriv);
> > - vcc->user_back = NULL;
> > -
> > - entry->recv_vcc->push = entry->old_recv_push;
> > - vcc_release_async(entry->recv_vcc, -EPIPE);
> > + if (vpriv) {
> > + kfree(vpriv);
> > + vcc->user_back = NULL;
> > + vcc->push = entry->old_recv_push;
> > + vcc_release_async(vcc, -EPIPE);
> >
> I wasn't going say anything, but since it seems like maybe you're going
> to redo this patch anyway. Changing "entry->recv_vcc->push" to
> "vcc->push" is obviously nice but could you do that in a separate
> patch?
>
> I use a tool to strip out the indenting changes:
> https://github.com/error27/rename_rev
>
> So when I review a patch like this, I want to pipe it to my script and
> just see:
>
> + if (vpriv) {
> vcc->pop = vpriv->old_pop;
> if (vpriv->xoff)
> netif_wake_queue(dev);
> kfree(vpriv);
> vcc->user_back = NULL;
> vcc->push = entry->old_push;
> vcc_release_async(vcc, -EPIPE);
> + }
> entry->vcc = NULL;
> }
> if (entry->recv_vcc) {
> struct atm_vcc *vcc = entry->recv_vcc;
> struct lec_vcc_priv *vpriv = LEC_VCC_PRIV(vcc);
>
> + if (vpriv) {
> kfree(vpriv);
> vcc->user_back = NULL;
>
> entry->recv_vcc->push = entry->old_recv_push;
> vcc_release_async(entry->recv_vcc, -EPIPE);
> + }
>
> The renames are nice but now I have to check things by hand.
Hi Dan,
Thanks for the review. You're right, the entry->recv_vcc->push to vcc->push rename should not be mixed into the bug fix patch.
I think I should only adds the if (vpriv) guards without any other changes.
I'll drop the cleanup rename entirely since this is legacy code and not worth a separate patch.
Best,
Jiayuan
> regards,
> dan carpenter
>
prev parent reply other threads:[~2026-02-25 11:33 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-24 4:46 [PATCH net v1] atm: lec: fix null-ptr-deref in lec_arp_clear_vccs Jiayuan Chen
2026-02-25 8:37 ` Simon Horman
2026-02-25 9:45 ` Simon Horman
2026-02-25 10:16 ` Jiayuan Chen
2026-02-25 11:12 ` Dan Carpenter
2026-02-25 13:27 ` Simon Horman
2026-02-25 10:58 ` Dan Carpenter
2026-02-25 11:32 ` Jiayuan Chen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6bc6f7fe686e53fe2aaca467920ccf300546d5bf@linux.dev \
--to=jiayuan.chen@linux.dev \
--cc=dan.carpenter@linaro.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=jiayuan.chen@shopee.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=syzbot+72e3ea390c305de0e259@syzkaller.appspotmail.com \
--cc=tglx@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.