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 01446346E5A; Thu, 30 Apr 2026 17:09:57 +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=1777568998; cv=none; b=rZkIozRLgLB+B0AaPnXtNtb8ZP1qmSJaZooGX0mz9ud4ljvH/cQ4PmN4Zhsci+4Z2bTWOb/IpaFIxf0JnQnlkiGaWfNDimEjQPR0bHv0b5OOslEmhLTqyX4fa4q0ilg5xPvSYDJbRywkO5nHef1zpOLYPHsZotiPeRZl+kF/qOw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777568998; c=relaxed/simple; bh=iQqCgFMI5z6iq1NiAFeIa69BDcAIBnEVEyxyv4ZzTW4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=LHIpFvePlb0TYfk4cCnODx5u2oB0eW2bmpWUqOX/r1blejhkjqWV/iG58JXoNUnxxaYtIIX1PgSRQqqYe82RPK8HvbxbhQH2SqIOC+iqF7yki8+3c5jTdGNQy4dBCJOv8Cx4QvmEC8eN8vEd9YwTQ55zNthhusfWoZ/K1xOjL80= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=kORl4kJS; 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="kORl4kJS" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 28718C2BCB3; Thu, 30 Apr 2026 17:09:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1777568997; bh=iQqCgFMI5z6iq1NiAFeIa69BDcAIBnEVEyxyv4ZzTW4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=kORl4kJSMh7G4oKwR529AGcpHSBoC8ZohAMCVm6NK4m/QcvXaqaDBivS7WPXfg8ib 2rHRDPrqDLBLDdAdnDAAjSup0CE5CPD4wslUUVVj6BsaaB4KHqNSmuyj1Fxp8gPIPB G0WV6ulaRlsl2Ar8iv83hIGCLBwZSJcySd56ht5FK8hxVFvIOC0EXPz56oMN8i6CiZ yFaXn9cLMSXO2X5E+r//EVFkCetRwnc915X8OyQzZnO9qlvcltm3yBldJQbOei3wGw /Fc+hzYtl01MxBkSeBsw38xEs1BGjGYY5QdSwuJAATaez5GiAvakY47FTQaxQ8b2Ly 7x2HQqdTb3Xgg== From: Simon Horman To: wei.fang@nxp.com Cc: 'Simon Horman' , claudiu.manoil@nxp.com, vladimir.oltean@nxp.com, xiaoning.wang@nxp.com, andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, imx@lists.linux.dev Subject: Re: [PATCH v3 net] net: enetc: fix VSI mailbox timeout handling and DMA lifecycle Date: Thu, 30 Apr 2026 18:09:22 +0100 Message-ID: <20260430170922.1729686-1-horms@kernel.org> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260429081930.3259824-1-wei.fang@nxp.com> References: <20260429081930.3259824-1-wei.fang@nxp.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: 'Simon Horman' This is an AI-generated review of your patch. The human sending this email has considered the AI review valid, or at least plausible. Full review at: https://sashiko.dev --- Subject: net: enetc: fix VSI mailbox timeout handling and DMA lifecycle This commit attempts to fix a use-after-free issue in the VSI mailbox send path by deferring the freeing of the DMA buffer if the hardware is still processing the message. The DMA buffer information is stored in the si structure and freed on the next send or when the driver is removed. [ ... ] > diff --git a/drivers/net/ethernet/freescale/enetc/enetc_vf.c b/drivers/net/ethernet/freescale/enetc/enetc_vf.c > --- a/drivers/net/ethernet/freescale/enetc/enetc_vf.c > +++ b/drivers/net/ethernet/freescale/enetc/enetc_vf.c [ ... ] > @@ -259,6 +282,7 @@ static void enetc_vf_remove(struct pci_dev *pdev) > { > struct enetc_si *si = pci_get_drvdata(pdev); > struct enetc_ndev_priv *priv; > + struct enetc_msg_swbd msg; > > priv = netdev_priv(si->ndev); > unregister_netdev(si->ndev); > @@ -270,7 +294,9 @@ static void enetc_vf_remove(struct pci_dev *pdev) > > free_netdev(si->ndev); > > + msg = si->msg; > enetc_pci_remove(pdev); > + enetc_msg_dma_free(&pdev->dev, &msg); Is it possible for the mailbox to still be busy here? The commit addresses the use-after-free in the send path by checking the mailbox busy status before freeing the previous buffer. However, during driver teardown, enetc_msg_dma_free() is called unconditionally. If a prior message sent via enetc_msg_vsi_send() times out and the hardware is still accessing the buffer, and then the driver is unbound, could this cause the hardware to read from freed DMA memory? Should the teardown path wait for the mailbox to become idle or ensure the hardware is safely reset before freeing the buffer? > }