From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5EFDC3B8D5C; Wed, 25 Feb 2026 13:27:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772026026; cv=none; b=dMBamufT9uOULd1Q6FtfYlBMkN2dV3TiUkVtDshN1TpcZ4UH0Jg7Z6O4DocDRJz9vTQjaC7WKT47kBpzDV5znEuaLRoQ6s9xnmDePsdwE+i7ped25yL4tiay2VCuNdYrQ7Kx48VrYhQUZDuN7KxyO7Dhywi+/Me6STTMfadUNpE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772026026; c=relaxed/simple; bh=SJDxOqpB+rKLyX3QxgwQ6DGI8UdwkTWWYVsinjovuRU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=a9ICT8JOwuxz3bPd1RJBb78i3iLr85YUdWHkIxpKisju33rSeNNfzKNA0nm6Wio/ofK6VQHq1s+zI7k7v1GypLcfUbYpnLs6xQgI/JAAQS9g0541jExMTQ1t+HBbVTy2qoH4L2U2jZJpT0AMFn0dhfbWF8QAWdxyMociGrDYkeE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Z8hK+HQt; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Z8hK+HQt" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9C624C116D0; Wed, 25 Feb 2026 13:27:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772026026; bh=SJDxOqpB+rKLyX3QxgwQ6DGI8UdwkTWWYVsinjovuRU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Z8hK+HQtKZAmEPdCT87pOuJPb0edyy4iN18icaLcwoJp5NWGCzmFo4JIO6BD9qwGg zkJU9eLqVd8WwiXVHyDj5r1VH3ZfpIJ1zFlnUA6IJjvZPwf+tvt8pjarxmVrf604pT gzhn5S+6kaa6898Nnsc6MX6vQg/XZMjuLkZYqRjEC76MYozIKHMJIkwPe2WucPqmDV 7xs6s+W14a36o0gGFNEA5dGQxQVPyqmD6DV3TGh/Qw1cakRrKi2kbCJzwHL+v1TTxY HTDInKyYiqnuf9XatLIiGnsfj68DY0G4bdWNBPFpOtQz3k4w5oo+TVv73aJTe9WnLq +IfdsSDchRdkw== Date: Wed, 25 Feb 2026 13:27:01 +0000 From: Simon Horman To: Jiayuan Chen Cc: netdev@vger.kernel.org, Jiayuan Chen , syzbot+72e3ea390c305de0e259@syzkaller.appspotmail.com, "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Ingo Molnar , Thomas Gleixner , Dan Carpenter , linux-kernel@vger.kernel.org Subject: Re: [PATCH net v1] atm: lec: fix null-ptr-deref in lec_arp_clear_vccs Message-ID: References: <20260224044648.243578-1-jiayuan.chen@linux.dev> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Wed, Feb 25, 2026 at 10:16:40AM +0000, Jiayuan Chen wrote: > February 25, 2026 at 17:45, "Simon Horman" wrote: > > > > > > On Wed, Feb 25, 2026 at 08:37:05AM +0000, Simon Horman wrote: > > > > > > > > On Tue, Feb 24, 2026 at 12:46:38PM +0800, Jiayuan Chen wrote: > > > From: Jiayuan Chen > > > > > > 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(). > > > > > Sorry for coming back to this a 2nd time. > > After thinking about this some more I'd like to pass on > > some feedback from the AI powered review. > > > > I'll put the full text below. But in a nutshell: could you clarify > > why it is necessary to avoid calling vcc_release_async() multiple times. > > > Hi Simon, > > Thanks for the feedback. > > 1. Regarding why it is necessary to avoid calling vcc_release_async() > multiple times: when vpriv is NULL, it means a previous call to > lec_arp_clear_vccs() has already freed vpriv, set vcc->user_back = NULL, > restored vcc->push, and called vcc_release_async() for this VCC. Calling > vcc_release_async() again on an already-released VCC would redundantly > set flags, set sk_err, and trigger sk_state_change() on a socket that is > already shutting down. While this may not cause an immediate crash, it is > semantically wrong — the VCC has already been properly released, and we > should not repeat the teardown sequence. > > That is why I intentionally placed the entire cleanup block (including > vcc_release_async()) inside the if (vpriv) guard, rather than only > guarding the vpriv dereference. The NULL vpriv serves as a reliable > indicator that this VCC has already been processed by a prior iteration. Thanks. I think it would be useful to include an explanation along those lines in the commit message. > 2. Regarding the Fixes tag: the AI suggests pointing to 8d9f73c0ad2f > ("atm: fix a memory leak of vcc->user_back"), but that only introduced > the entry->recv_vcc cleanup path. The entry->vcc path has had the same > bug since the beginning — if two ARP entries share the same VCC, the > second call dereferences NULL vpriv via vcc->pop = vpriv->old_pop. My > patch fixes both paths, and the entry->vcc path bug traces back to the > original code, so Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") is correct. > I've verified that the entry->vcc path is independently triggerable with > a seperated reproducer [1] (it's not worth to put it into selftest for > legacy module) > > I also don't think splitting this into two patches makes sense — both > paths are in the same function, exhibit the same bug pattern, and the fix > is identical. Understood. I agree the code changes make sense to keep together in a single patch. And retain the Fixes tag as you have it. ...