From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 785F93FADF6 for ; Thu, 4 Jun 2026 21:23:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780608202; cv=none; b=s6gesV348RSjg5un0ipjgA5x+Z87HF0tHbOQQjeqCy/EsyfEFlJc+c0+XN0ro5J8Z7r4FMyg+N/f0Yk1zXix1uvosBZisyczJ8YaMBlYLlgSb9EHZZDFnk4S1j6akxRuIO4mlCQ25g5eb/Zw07thfwEgVVR/aiXis7XrxGJ3GjU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780608202; c=relaxed/simple; bh=0xer4wn2tCTzWbs5uLYTskx4FaXA/2EiMQZeA7em6p4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=opKjT36qVEUVopHPScXCtJezztjed+PVRqz64RTcwT9mZbtSTkZl/AN/ETtuQ8OJano7hT4iuFL6bK/gZxF6MWS9kZrL1RGMgb4AVveBeZ3+ElZhNkG39zqX98rud5Qd3BSM6k4tu5kdVStc1jm/0pN0cHSsJIachxuRQQtjw14= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=UJNpkEQt; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="UJNpkEQt" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5B1AE1F00893; Thu, 4 Jun 2026 21:23:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1780608200; bh=sTEc98M4XZy4WMkROG0qptNsTU3Fmgz7V9VTlpGoaVk=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=UJNpkEQt0CjkCEugmUYRNBhibW8aOtscYwd1wNIXNfvnqPgDBnxZiY1nhmlqv7+ny 9mbOZCovyunje6G1Z6EhgfiE+hADo5LdmjDPBYtBqZNZR7IYQ7SG5JeBDyIrOksuln KS8Inh2I2jYGs+sE1IKgZqGLLnBca+6vlZnRACzPDmofakkIHTRD6hWN6cio3Jy8Mq qZxdLtODHaz/gheWt60QtP04MNza/uKK4d9+wqPt3TpMcIrZPheJj1MqZ7azgqTTsm 2w6ortBrQUgasNRO1mQtECATG3HqNSdo9d0FDnAY38MpMKIIQzamgNGoHFDx8P4jrY 7k5oLWJK437Hw== Date: Thu, 4 Jun 2026 23:23:16 +0200 From: Lorenzo Bianconi To: Jacob Keller Cc: Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Felix Fietkau , Matthias Brugger , AngeloGioacchino Del Regno , Florian Westphal , linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, netdev@vger.kernel.org Subject: Re: [PATCH net 1/2] net: airoha: Fix use-after-free in metadata dst teardown Message-ID: References: <20260602-airoha-mtk-metadata-uaf-fix-v1-0-3aaa99d83351@kernel.org> <20260602-airoha-mtk-metadata-uaf-fix-v1-1-3aaa99d83351@kernel.org> <21810a20-abe6-4490-969c-cfd62c4c082a@intel.com> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="aWp9RvEMdmSaWjBX" Content-Disposition: inline In-Reply-To: <21810a20-abe6-4490-969c-cfd62c4c082a@intel.com> --aWp9RvEMdmSaWjBX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > On 6/2/2026 2:21 AM, Lorenzo Bianconi wrote: > > airoha_metadata_dst_free() runs metadata_dst_free() which frees the > > metadata_dst with kfree() immediately, bypassing the RCU grace period. > > In the RX path, skb_dst_set_noref() sets a non-refcounted pointer from > > the skb to the metadata_dst. This function requires RCU read-side > > protection and the dst must remain valid until all RCU readers complete. > > Since metadata_dst_free() calls kfree() directly, an use-after-free can > > occur if any skb still holds a noref pointer to the dst when the driver > > tears it down. > > Replace metadata_dst_free() with dst_release() which properly goes > > through the refcount path: when the refcount drops to zero, it schedules > > the actual free via call_rcu_hurry(), ensuring all RCU readers have > > completed before the memory is freed. > >=20 > > Fixes: af3cf757d5c9 ("net: airoha: Move DSA tag in DMA descriptor") > > Signed-off-by: Lorenzo Bianconi > > --- > > drivers/net/ethernet/airoha/airoha_eth.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > >=20 > > diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/eth= ernet/airoha/airoha_eth.c > > index cecd66251dba..eab6a98d62b9 100644 > > --- a/drivers/net/ethernet/airoha/airoha_eth.c > > +++ b/drivers/net/ethernet/airoha/airoha_eth.c > > @@ -2936,7 +2936,7 @@ static void airoha_metadata_dst_free(struct airoh= a_gdm_port *port) > > if (!port->dsa_meta[i]) > > continue; > > =20 > > - metadata_dst_free(port->dsa_meta[i]); > > + dst_release(&port->dsa_meta[i]->dst); > > } > > } > > =20 > >=20 >=20 > the port->dsa_meta is allocated using metadata_dst_alloc().. how is it > safe to use dst_release here? Seems like we should be calling dst_alloc > instead of metadata_dst_alloc in order to use dst_release?? We need to allocate the metadata_dst using metadata_dst_alloc() since md_dst->u.port_info.port_id is consumed in dsa_switch_rcv() to get the switch conduit port. I guess it is fine to free metadata_dst running dst_release() since dst_ini= t() sets DST_METADATA flag and so dst_destroy() runs metadata_dst_free() after = the RCU grace period. >=20 > metadata_dst_alloc does call __metadata_dst_init which calls dst_init.. >=20 > I guess the start of the metadata_dst structure is also the same address > as the internal dst_entry struct... >=20 > But dst_destroy does a whole lot more than metadata_dst_release so I > don't feel confident in this actually being a drop-in replacement... It > calls netdev_put, it calls the dst->ops->destroy, it releases child > refs.. Or for metadata dst entries is that all basically a no-op?? __metadata_dst_init() calls dst_init() with dev =3D NULL so netdev_put() is= a no-op. Same for dst->ops is dst_blackhole_ops and and dst_blackhole_ops has= no destroy callback. >=20 > I feel like I'm missing something here.. The driver also calls > metadata_dst_free in the remove path and that wasn't changed by this > patch either. can you please explain what you mean here? we do not run metadata_dst_free() anymore. Regards, Lorenzo >=20 > Generally it seems like we should be using the same API to allocate as > to release the object... This is confusing. What am I missing? --aWp9RvEMdmSaWjBX Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQTquNwa3Txd3rGGn7Y6cBh0uS2trAUCaiHswQAKCRA6cBh0uS2t rHipAP4llkXraaMXUK3wGAgySlJJUwlEcRj8tHK/o/3m+eELXwEA2l1QByKUIy8/ sBrHvIWNbv90x/tGgmBZkNoYSKAXpAo= =ev4h -----END PGP SIGNATURE----- --aWp9RvEMdmSaWjBX--