From: Wei Fang <wei.fang@nxp.com>
To: 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
Cc: imx@lists.linux.dev, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, catalin.horghidan@nxp.com
Subject: [PATCH net 2/6] net: enetc: fix race condition in VF MAC address configuration
Date: Wed, 13 May 2026 18:30:17 +0800 [thread overview]
Message-ID: <20260513103021.2190593-3-wei.fang@nxp.com> (raw)
In-Reply-To: <20260513103021.2190593-1-wei.fang@nxp.com>
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>
---
drivers/net/ethernet/freescale/enetc/enetc_pf.c | 10 ++++++++++
drivers/net/ethernet/freescale/enetc/enetc_pf.h | 1 +
2 files changed, 11 insertions(+)
diff --git a/drivers/net/ethernet/freescale/enetc/enetc_pf.c b/drivers/net/ethernet/freescale/enetc/enetc_pf.c
index 756614ffa8c6..6939ab04dcdc 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;
}
@@ -499,12 +503,15 @@ 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)
dev_warn(dev, "Attempt to override PF set mac addr for VF%d\n",
vf_id);
else
enetc_pf_set_primary_mac_addr(&pf->si->hw, vf_id + 1, addr);
+ mutex_unlock(&vf_state->lock);
+
return ENETC_MSG_CMD_STATUS_OK;
}
@@ -968,6 +975,9 @@ static int enetc_pf_probe(struct pci_dev *pdev,
pf->total_vfs);
if (!pf->vf_state)
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;
};
--
2.34.1
next prev parent reply other threads:[~2026-05-13 10:57 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-13 10:30 [PATCH net 0/6] net: enetc: SR-IOV robustness and security fixes Wei Fang
2026-05-13 10:30 ` [PATCH net 1/6] net: enetc: validate VF primary MAC address before configuration Wei Fang
2026-05-13 10:30 ` Wei Fang [this message]
2026-05-13 10:30 ` [PATCH net 3/6] net: enetc: fix use-after-free in mailbox cleanup on interrupt race Wei Fang
2026-05-13 10:30 ` [PATCH net 4/6] net: enetc: avoid VF->PF mailbox timeout during SR-IOV teardown Wei Fang
2026-05-13 10:30 ` [PATCH net 5/6] net: enetc: fix initialization order to prevent use of uninitialized resources Wei Fang
2026-05-13 10:30 ` [PATCH net 6/6] net: enetc: add ratelimiting to VF mailbox error messages Wei Fang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260513103021.2190593-3-wei.fang@nxp.com \
--to=wei.fang@nxp.com \
--cc=andrew+netdev@lunn.ch \
--cc=catalin.horghidan@nxp.com \
--cc=claudiu.manoil@nxp.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=imx@lists.linux.dev \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=vladimir.oltean@nxp.com \
--cc=xiaoning.wang@nxp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox