quoted

@@ -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?

enetc_msg_dma_free() is called after enetc_pci_remove(), enetc_pci_remove()
will disable the device, so it is safe to free the buffer.