From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from stravinsky.debian.org (stravinsky.debian.org [82.195.75.108]) (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 E22D530676C; Fri, 3 Jul 2026 16:32:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=82.195.75.108 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783096353; cv=none; b=LDA49MaCSoO0P3CfXLG+UBsLSoYE8hWbQocUV8Ufo+TwSp9dBZQnP85NF9e9wIhxXVwOhiTjqGFIU0S2wOs9EONjFK4Bg1jetzackFGMiG/VRhpvx5yPg709u4heLhmnJtxGhoUEXvvwr4sSipNST9dJwmgv6j+DEhSDFiGKNQU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783096353; c=relaxed/simple; bh=iWwxwAJqrUrtoedwvx91WuQ6lfaBcCZ4LuzX89+iq2o=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=LkgdJFlyIhQn9XXvQOOpvnscAEpYhsGhcahQEgiPiJAZZ9/MLCSgDLTMZvR3IAOFnj4bQO/GHtr1jfHu9nnqkQ/hQMRQi/XZ6Zmp7IO7+DNbJ7gQpHYbYUXTxBGP5RDPTajgMr116kXxBGM5NVD4MHsJEAej7lg313+Ph7DS06k= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=debian.org; spf=pass smtp.mailfrom=debian.org; dkim=pass (2048-bit key) header.d=debian.org header.i=@debian.org header.b=t8lsb6V/; arc=none smtp.client-ip=82.195.75.108 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=debian.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=debian.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=debian.org header.i=@debian.org header.b="t8lsb6V/" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debian.org; s=smtpauto.stravinsky; h=X-Debian-User:In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=rnGKoTM+HfxOQZzAszLgDjImXbDy85Rf530KP4A8t00=; b=t8lsb6V//RGmO6WQVIl+7MIMKU NwSpU32o2UfagDpWt29euEXX//vsd2UAlupZ4QTm2oukjjygWXRS8IBJbbn3rny8djnOoWDjspDPV 6k+l3WM/au7rkJ8jMmjKiL64Y3gWlUTyAkyzsZoIApHTJtHMhzk3XF3SHbdUEexfQQuRA3nDOBjkf i+TjP4FIvi/hdzg15CDns6NuIm2VFcE25iRfDVys+Bh2wIn2ve3/UkW6EEmUCl5CfmiWYuQRWwsdw 2W5ihbSwhoAO3p+VO6cJcc3fLT9v3yNVYZ3TCW3DtyhfMzuDrW/8yM/+cfrsuVmJMp+E0lIUQkSAw 62ClD6ow==; Received: from authenticated-user by stravinsky.debian.org with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.96) (envelope-from ) id 1wfgoP-009WtZ-2l; Fri, 03 Jul 2026 16:32:22 +0000 Date: Fri, 3 Jul 2026 09:32:16 -0700 From: Breno Leitao To: Qingfang Deng Cc: Norbert Szetei , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Sebastian Andrzej Siewior , Taegu Ha , Kees Cook , linux-ppp@vger.kernel.org, linux-kernel@vger.kernel.org, Guillaume Nault , netdev@vger.kernel.org Subject: Re: [PATCH net v2] ppp: defer channel free to an RCU grace period to fix pppol2tp RX UAF Message-ID: References: Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Debian-User: leitao On Fri, Jul 03, 2026 at 03:27:00PM +0800, Qingfang Deng wrote: > Hi, > > On 2026/7/2 2:12, Norbert Szetei wrote: > > +/* Purge after the grace period: a late ppp_input() may still queue an > > + * skb on pch->file.rq before the last RCU reader drains. > > + */ > > +static void ppp_release_channel_free(struct rcu_head *rcu) > > +{ > > + struct channel *pch = container_of(rcu, struct channel, rcu); > > + > > + skb_queue_purge(&pch->file.xq); > > + skb_queue_purge(&pch->file.rq); > > + kfree(pch); > > +} > > + > > /* > > * Drop a reference to a ppp channel and free its memory if the refcount reaches > > * zero. > > @@ -3581,9 +3594,7 @@ static void ppp_release_channel(struct channel *pch) > > pr_err("ppp: destroying undead channel %p !\n", pch); > > return; > > } > > - skb_queue_purge(&pch->file.xq); > > - skb_queue_purge(&pch->file.rq); > > - kfree(pch); > > + call_rcu(&pch->rcu, ppp_release_channel_free); > > } > > static void __exit ppp_cleanup(void) > > AI-review found an issue: https://sashiko.dev/#/patchset/D9C0245B-608B-4884-8A09-F55BA4A9F948%40doyensec.com > > An rcu_barrier() call is needed at the end of ppp_cleanup(). I was initially unclear why rcu_barrier() would be necessary on a kfree path, but it appears to be required during module unload to ensure that ppp_release_channel_free() completes before the module's struct rcu_head is destroyed. Is that the correct understanding?