Commit f262f5d89332 for kernel

commit f262f5d893327a7131ed25ac8dd01ed7024bcc18
Author: Wei Fang <wei.fang@nxp.com>
Date:   Wed May 20 14:44:17 2026 +0800

    net: enetc: fix race condition in VF MAC address configuration

    Sashiko reported a potential race condition between the VF message
    handler and administrative VF MAC configuration from the host [1].

    The VF message handler (enetc_msg_pf_set_vf_primary_mac_addr) runs
    asynchronously in a workqueue context and accesses vf_state->flags
    without any locking. Concurrently, the host can administratively
    change the VF MAC address via enetc_pf_set_vf_mac(), which executes
    under RTNL lock and modifies both vf_state->flags and hardware
    registers.

    This creates two race windows:

    1) TOCTOU race on vf_state->flags: The check of ENETC_VF_FLAG_PF_SET_MAC
       and subsequent MAC programming are not atomic, allowing the flag state
       to change between check and use.

    2) Torn MAC address writes: Hardware MAC programming requires multiple
       non-atomic register writes (__raw_writel for lower 32 bits and
       __raw_writew for upper 16 bits). Concurrent updates from VF mailbox
       and PF admin paths can interleave these operations, resulting in a
       corrupted MAC address being programmed into the hardware.

    Fix by introducing a per-VF mutex to serialize access to vf_state and
    hardware MAC register updates. Both enetc_pf_set_vf_mac() and
    enetc_msg_pf_set_vf_primary_mac_addr() now acquire this lock before
    accessing vf_state->flags or programming the MAC address, ensuring
    atomic read-modify-write sequences and preventing register write
    interleaving.

    Link: https://sashiko.dev/#/patchset/20260511080805.2052495-1-wei.fang%40nxp.com #1
    Fixes: beb74ac878c8 ("enetc: Add vf to pf messaging support")
    Signed-off-by: Wei Fang <wei.fang@nxp.com>
    Reviewed-by: Harshitha Ramamurthy <hramamurthy@google.com>
    Link: https://patch.msgid.link/20260520064421.91569-6-wei.fang@nxp.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>

diff --git a/drivers/net/ethernet/freescale/enetc/enetc_pf.c b/drivers/net/ethernet/freescale/enetc/enetc_pf.c
index 09c642040892..8e11a023d516 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_pf.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc_pf.c
@@ -252,8 +252,12 @@ static int enetc_pf_set_vf_mac(struct net_device *ndev, int vf, u8 *mac)
 		return -EADDRNOTAVAIL;

 	vf_state = &pf->vf_state[vf];
+
+	mutex_lock(&vf_state->lock);
 	vf_state->flags |= ENETC_VF_FLAG_PF_SET_MAC;
 	enetc_pf_set_primary_mac_addr(&priv->si->hw, vf + 1, mac);
+	mutex_unlock(&vf_state->lock);
+
 	return 0;
 }

@@ -496,7 +500,9 @@ static u16 enetc_msg_pf_set_vf_primary_mac_addr(struct enetc_pf *pf,
 		return ENETC_MSG_CMD_STATUS_FAIL;
 	}

+	mutex_lock(&vf_state->lock);
 	if (vf_state->flags & ENETC_VF_FLAG_PF_SET_MAC) {
+		mutex_unlock(&vf_state->lock);
 		dev_err_ratelimited(dev,
 				    "VF%d attempted to override PF set MAC\n",
 				    vf_id);
@@ -504,6 +510,7 @@ static u16 enetc_msg_pf_set_vf_primary_mac_addr(struct enetc_pf *pf,
 	}

 	enetc_pf_set_primary_mac_addr(&pf->si->hw, vf_id + 1, addr);
+	mutex_unlock(&vf_state->lock);

 	return ENETC_MSG_CMD_STATUS_OK;
 }
@@ -989,6 +996,9 @@ static int enetc_pf_probe(struct pci_dev *pdev,
 			err = -ENOMEM;
 			goto err_alloc_vf_state;
 		}
+
+		for (int i = 0; i < pf->total_vfs; i++)
+			mutex_init(&pf->vf_state[i].lock);
 	}

 	err = enetc_setup_mac_addresses(node, pf);
diff --git a/drivers/net/ethernet/freescale/enetc/enetc_pf.h b/drivers/net/ethernet/freescale/enetc/enetc_pf.h
index ae407e9e9ee7..35d484858c7b 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_pf.h
+++ b/drivers/net/ethernet/freescale/enetc/enetc_pf.h
@@ -14,6 +14,7 @@ enum enetc_vf_flags {
 };

 struct enetc_vf_state {
+	struct mutex lock; /* Prevent concurrent access */
 	enum enetc_vf_flags flags;
 };