[PATCH v2 net 0/9] net: enetc: SR-IOV robustness and security fixes

[PATCH v2 net 0/9] net: enetc: SR-IOV robustness and security fixes

[Wei Fang]

This patch series addresses a number of robustness, security, and
correctness issues in the ENETC driver's SR-IOV subsystem, focusing
primarily on the VF-to-PF mailbox communication path.

The series can be grouped into the following categories:

1. DoS and security fixes:
   - Prevent an unbounded loop DoS in the VF-to-PF message handler,
     which could be triggered by a malicious or misbehaving VF.
   - Fix a TOCTOU (Time-of-Check-Time-of-Use) race and add proper
     validation of VF MAC addresses to prevent spoofing or invalid
     configuration from being applied.

2. Race condition fixes:
   - Fix a race condition in VF MAC address configuration that could
     lead to inconsistent state between the VF request and PF
     application.
   - Fix a race condition during SR-IOV teardown that could cause
     VF->PF mailbox operations to time out, resulting in unnecessary
     errors during shutdown.

3. Memory safety fixes:
   - Fix a DMA write to freed memory in enetc_msg_free_mbx(), which
     could cause silent memory corruption or system instability.

4. Error handling and initialization fixes:
   - Fix missing error code propagation when pf->vf_state allocation
     fails, ensuring callers receive a proper errno instead of
     succeeding silently.
   - Fix incorrect mailbox message status values returned to VFs,
     which could cause VFs to misinterpret PF responses.
   - Fix initialization order to prevent the use of uninitialized
     resources during driver probe, which could cause undefined
     behavior on certain configurations.

5. Diagnostics improvement:
   - Add rate limiting to VF mailbox error messages to prevent log
     flooding in the presence of a misbehaving VF.

These fixes improve the overall stability and security of the ENETC
SR-IOV implementation, particularly in multi-tenant environments where
VFs may be assigned to untrusted guests.

---
v2:
1. Copy the message content from DMA memory to local memory
2. Patch 3 and 5 in v1 are merged into patch 8 in v2
3. Add more fix patches, such as patch 1, 2, 6 and 7
v1 link: https://lore.kernel.org/imx/20260513103021.2190593-1-wei.fang@nxp.com/
---

Wei Fang (9):
  net: enetc: fix incorrect mailbox message status returned to VFs
  net: enetc: fix missing error code when pf->vf_state allocation fails
  net: enetc: add ratelimiting to VF mailbox error messages
  net: enetc: fix TOCTOU race and validate VF MAC address
  net: enetc: fix race condition in VF MAC address configuration
  net: enetc: fix DMA write to freed memory in enetc_msg_free_mbx()
  net: enetc: fix VF-to-PF message handler unbounded loop DoS
  net: enetc: fix initialization order to prevent use of uninitialized
    resources
  net: enetc: avoid VF->PF mailbox timeout during SR-IOV teardown

 .../net/ethernet/freescale/enetc/enetc_hw.h   |  1 +
 .../net/ethernet/freescale/enetc/enetc_msg.c  | 79 ++++++++++---------
 .../net/ethernet/freescale/enetc/enetc_pf.c   | 75 +++++++++++++-----
 .../net/ethernet/freescale/enetc/enetc_pf.h   |  1 +
 4 files changed, 98 insertions(+), 58 deletions(-)

-- 
2.34.1

[PATCH v2 net 1/9] net: enetc: fix incorrect mailbox message status returned to VFs

[Wei Fang]

There are two cases where VFs receive an incorrect success status from
the PF mailbox message handler, misleading them into believing their
requests have been fulfilled:

In enetc_msg_handle_rxmsg(), *status is pre-initialized to
ENETC_MSG_CMD_STATUS_OK. When an unsupported command type is received,
the default case only logs an error without updating *status, so it
remains as ENETC_MSG_CMD_STATUS_OK.

In enetc_msg_pf_set_vf_primary_mac_addr(), when the PF has already
assigned a MAC address for the VF (ENETC_VF_FLAG_PF_SET_MAC is set),
the function rejects the request but returns ENETC_MSG_CMD_STATUS_OK
instead of ENETC_MSG_CMD_STATUS_FAIL.

Therefore, correct the status value for the two cases mentioned above.

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 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/freescale/enetc/enetc_pf.c b/drivers/net/ethernet/freescale/enetc/enetc_pf.c
index a12fd54a475f..27d4bb65e017 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_pf.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc_pf.c
@@ -493,11 +493,13 @@ static u16 enetc_msg_pf_set_vf_primary_mac_addr(struct enetc_pf *pf,
 		return ENETC_MSG_CMD_STATUS_FAIL;
 
 	addr = cmd->mac.sa_data;
-	if (vf_state->flags & ENETC_VF_FLAG_PF_SET_MAC)
+	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);
+		return ENETC_MSG_CMD_STATUS_FAIL;
+	}
+
+	enetc_pf_set_primary_mac_addr(&pf->si->hw, vf_id + 1, addr);
 
 	return ENETC_MSG_CMD_STATUS_OK;
 }
@@ -509,7 +511,6 @@ void enetc_msg_handle_rxmsg(struct enetc_pf *pf, int vf_id, u16 *status)
 	struct enetc_msg_cmd_header *cmd_hdr;
 	u16 cmd_type;
 
-	*status = ENETC_MSG_CMD_STATUS_OK;
 	cmd_hdr = (struct enetc_msg_cmd_header *)msg->vaddr;
 	cmd_type = cmd_hdr->type;
 
@@ -518,6 +519,7 @@ void enetc_msg_handle_rxmsg(struct enetc_pf *pf, int vf_id, u16 *status)
 		*status = enetc_msg_pf_set_vf_primary_mac_addr(pf, vf_id);
 		break;
 	default:
+		*status = ENETC_MSG_CMD_STATUS_FAIL;
 		dev_err(dev, "command not supported (cmd_type: 0x%x)\n",
 			cmd_type);
 	}
-- 
2.34.1

[PATCH v2 net 2/9] net: enetc: fix missing error code when pf->vf_state allocation fails

[Wei Fang]

In enetc_pf_probe(), when the memory allocation for pf->vf_state fails,
the code jumps to the error handling label but the variable 'err' is not
assigned an appropriate error code beforehand. This causes the function
to return 0 (success) on an allocation failure path, misleading the
caller into thinking the probe succeeded. So set err to -ENOMEM before
jumping to the error handling label when the allocation for pf->vf_state
returns NULL.

Fixes: e15c5506dd39 ("net: enetc: allocate vf_state during PF probes")
Signed-off-by: Wei Fang <wei.fang@nxp.com>
---
 drivers/net/ethernet/freescale/enetc/enetc_pf.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/freescale/enetc/enetc_pf.c b/drivers/net/ethernet/freescale/enetc/enetc_pf.c
index 27d4bb65e017..b743b6d33ccc 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_pf.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc_pf.c
@@ -962,8 +962,10 @@ static int enetc_pf_probe(struct pci_dev *pdev,
 	if (pf->total_vfs) {
 		pf->vf_state = kzalloc_objs(struct enetc_vf_state,
 					    pf->total_vfs);
-		if (!pf->vf_state)
+		if (!pf->vf_state) {
+			err = -ENOMEM;
 			goto err_alloc_vf_state;
+		}
 	}
 
 	err = enetc_setup_mac_addresses(node, pf);
-- 
2.34.1

[PATCH v2 net 3/9] net: enetc: add ratelimiting to VF mailbox error messages

[Wei Fang]

Sashiko reported that a buggy or malicious guest VM can flood the host
kernel log by repeatedly sending VF-to-PF messages at a high rate,
degrading host performance and hiding important system logs [1].

Fix by replacing dev_err()/dev_warn() with dev_err_ratelimited(),
limiting output to the default kernel ratelimit. This ensures errors are
still logged for debugging while preventing log flooding attacks.

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 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/freescale/enetc/enetc_pf.c b/drivers/net/ethernet/freescale/enetc/enetc_pf.c
index b743b6d33ccc..dea3a92c4722 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_pf.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc_pf.c
@@ -494,8 +494,9 @@ static u16 enetc_msg_pf_set_vf_primary_mac_addr(struct enetc_pf *pf,
 
 	addr = cmd->mac.sa_data;
 	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);
+		dev_err_ratelimited(dev,
+				    "VF%d attempted to override PF set MAC\n",
+				    vf_id);
 		return ENETC_MSG_CMD_STATUS_FAIL;
 	}
 
@@ -520,8 +521,9 @@ void enetc_msg_handle_rxmsg(struct enetc_pf *pf, int vf_id, u16 *status)
 		break;
 	default:
 		*status = ENETC_MSG_CMD_STATUS_FAIL;
-		dev_err(dev, "command not supported (cmd_type: 0x%x)\n",
-			cmd_type);
+		dev_err_ratelimited(dev,
+				    "command not supported (cmd_type: 0x%x)\n",
+				    cmd_type);
 	}
 }
 
-- 
2.34.1

[PATCH v2 net 4/9] net: enetc: fix TOCTOU race and validate VF MAC address

[Wei Fang]

Sashiko reported that the PF driver accepts arbitrary MAC address from
from VF mailbox messages without proper validation, creating a security
vulnerability [1].

In enetc_msg_pf_set_vf_primary_mac_addr(), the MAC address is extracted
directly from the message buffer (cmd->mac.sa_data) and programmed into
hardware via pf->ops->set_si_primary_mac() without any validity checks.
A malicious VF can configure a multicast, broadcast, or all-zero MAC
address. Therefore, a validation to check the MAC address provided by VF
is required.

However, simply checking the MAC address is not enough, because it also
has the potential TOCTOU race [2]: The code reads the MAC address from
the DMA buffer to validate it via is_valid_ether_addr(), if validation
passes, reads the same DMA buffer a second time when calling
enetc_pf_set_primary_mac_addr() to program the hardware. A malicious VF
can exploit this window by overwriting the MAC address in the DMA buffer
between the validation check and the hardware programming, bypassing the
validation entirely.

Therefore, allocate a local buffer in enetc_msg_handle_rxmsg() and copy
the message content from the DMA buffer via memcpy() before processing.
This ensures the PF operates on a stable snapshot that the VF cannot
modify.

Link: https://sashiko.dev/#/patchset/20260511080805.2052495-1-wei.fang%40nxp.com #1
Link: https://sashiko.dev/#/patchset/20260513103021.2190593-1-wei.fang%40nxp.com #2
Fixes: beb74ac878c8 ("enetc: Add vf to pf messaging support")
Signed-off-by: Wei Fang <wei.fang@nxp.com>
---
 .../net/ethernet/freescale/enetc/enetc_pf.c   | 39 ++++++++++++++-----
 1 file changed, 30 insertions(+), 9 deletions(-)

diff --git a/drivers/net/ethernet/freescale/enetc/enetc_pf.c b/drivers/net/ethernet/freescale/enetc/enetc_pf.c
index dea3a92c4722..09c642040892 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_pf.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc_pf.c
@@ -478,21 +478,24 @@ static void enetc_configure_port(struct enetc_pf *pf)
 
 /* Messaging */
 static u16 enetc_msg_pf_set_vf_primary_mac_addr(struct enetc_pf *pf,
-						int vf_id)
+						int vf_id, void *msg)
 {
 	struct enetc_vf_state *vf_state = &pf->vf_state[vf_id];
-	struct enetc_msg_swbd *msg = &pf->rxmsg[vf_id];
-	struct enetc_msg_cmd_set_primary_mac *cmd;
+	struct enetc_msg_cmd_set_primary_mac *cmd = msg;
 	struct device *dev = &pf->si->pdev->dev;
-	u16 cmd_id;
+	u16 cmd_id = cmd->header.id;
 	char *addr;
 
-	cmd = (struct enetc_msg_cmd_set_primary_mac *)msg->vaddr;
-	cmd_id = cmd->header.id;
 	if (cmd_id != ENETC_MSG_CMD_MNG_ADD)
 		return ENETC_MSG_CMD_STATUS_FAIL;
 
 	addr = cmd->mac.sa_data;
+	if (!is_valid_ether_addr(addr)) {
+		dev_err_ratelimited(dev, "VF%d attempted to set invalid MAC\n",
+				    vf_id);
+		return ENETC_MSG_CMD_STATUS_FAIL;
+	}
+
 	if (vf_state->flags & ENETC_VF_FLAG_PF_SET_MAC) {
 		dev_err_ratelimited(dev,
 				    "VF%d attempted to override PF set MAC\n",
@@ -507,17 +510,33 @@ static u16 enetc_msg_pf_set_vf_primary_mac_addr(struct enetc_pf *pf,
 
 void enetc_msg_handle_rxmsg(struct enetc_pf *pf, int vf_id, u16 *status)
 {
-	struct enetc_msg_swbd *msg = &pf->rxmsg[vf_id];
+	struct enetc_msg_swbd *msg_swbd = &pf->rxmsg[vf_id];
 	struct device *dev = &pf->si->pdev->dev;
 	struct enetc_msg_cmd_header *cmd_hdr;
 	u16 cmd_type;
+	u8 *msg;
 
-	cmd_hdr = (struct enetc_msg_cmd_header *)msg->vaddr;
+	msg = kzalloc_objs(*msg, msg_swbd->size);
+	if (!msg) {
+		dev_err_ratelimited(dev,
+				    "Failed to allocate message buffer\n");
+		*status = ENETC_MSG_CMD_STATUS_FAIL;
+		return;
+	}
+
+	/* Currently, only ENETC_MSG_CMD_MNG_MAC command is supported, so
+	 * only sizeof(struct enetc_msg_cmd_set_primary_mac) bytes need to
+	 * be copied. This data already includes the cmd_type field, so it
+	 * can correctly return an error code.
+	 */
+	memcpy(msg, msg_swbd->vaddr,
+	       sizeof(struct enetc_msg_cmd_set_primary_mac));
+	cmd_hdr = (struct enetc_msg_cmd_header *)msg;
 	cmd_type = cmd_hdr->type;
 
 	switch (cmd_type) {
 	case ENETC_MSG_CMD_MNG_MAC:
-		*status = enetc_msg_pf_set_vf_primary_mac_addr(pf, vf_id);
+		*status = enetc_msg_pf_set_vf_primary_mac_addr(pf, vf_id, msg);
 		break;
 	default:
 		*status = ENETC_MSG_CMD_STATUS_FAIL;
@@ -525,6 +544,8 @@ void enetc_msg_handle_rxmsg(struct enetc_pf *pf, int vf_id, u16 *status)
 				    "command not supported (cmd_type: 0x%x)\n",
 				    cmd_type);
 	}
+
+	kfree(msg);
 }
 
 #ifdef CONFIG_PCI_IOV
-- 
2.34.1

[PATCH v2 net 5/9] net: enetc: fix race condition in VF MAC address configuration

[Wei Fang]

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 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;
 };
 
-- 
2.34.1

[PATCH v2 net 6/9] net: enetc: fix DMA write to freed memory in enetc_msg_free_mbx()

[Wei Fang]

The teardown sequence in enetc_msg_psi_free() frees the DMA buffer before
clearing the device's DMA address registers. If a VF sends a message or a
pending DMA transfer completes within this window, the hardware will
perform a DMA write into the kernel memory that has already been returned
to the allocator.

The result is silent memory corruption that can affect arbitrary kernel
data structures. Therefore, clear the DMA address registers before the
DMA buffer is freed.

Fixes: beb74ac878c8 ("enetc: Add vf to pf messaging support")
Signed-off-by: Wei Fang <wei.fang@nxp.com>
---
 drivers/net/ethernet/freescale/enetc/enetc_msg.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/freescale/enetc/enetc_msg.c b/drivers/net/ethernet/freescale/enetc/enetc_msg.c
index 40d22ebe9224..b4d7457097e6 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_msg.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc_msg.c
@@ -96,12 +96,12 @@ static void enetc_msg_free_mbx(struct enetc_si *si, int idx)
 	struct enetc_hw *hw = &si->hw;
 	struct enetc_msg_swbd *msg;
 
+	enetc_wr(hw, ENETC_PSIVMSGRCVAR0(idx), 0);
+	enetc_wr(hw, ENETC_PSIVMSGRCVAR1(idx), 0);
+
 	msg = &pf->rxmsg[idx];
 	dma_free_coherent(&si->pdev->dev, msg->size, msg->vaddr, msg->dma);
 	memset(msg, 0, sizeof(*msg));
-
-	enetc_wr(hw, ENETC_PSIVMSGRCVAR0(idx), 0);
-	enetc_wr(hw, ENETC_PSIVMSGRCVAR1(idx), 0);
 }
 
 int enetc_msg_psi_init(struct enetc_pf *pf)
-- 
2.34.1

[PATCH v2 net 7/9] net: enetc: fix VF-to-PF message handler unbounded loop DoS

[Wei Fang]

enetc_msg_task() processes VF-to-PF mailbox messages using an unbounded
for(;;) loop that repeatedly polls ENETC_PSIMSGRR until no MR bits set.

A malicious guest VM can exploit this by immediately sending a new
message as soon as the PF acknowledges the previous one via a w1c write
to ENETC_PSIMSGRR. Since there is no processing budget or yield point,
a VF can keep the MR bit continuously re-asserted, preventing the loop
from ever terminating and starving other tasks on the PF worker thread.

Fix this by replacing the unbounded loop with a single snapshot read of
ENETC_PSIMSGRR at task entry. The task processes only the VFs whose MR
bits were set at that point, clears the corresponding bits in
ENETC_PSIMSGRR and ENETC_PSIIDR, and re-enables the message interrupt
before returning.

No messages are lost: the message interrupt is disabled before
enetc_msg_task() is scheduled (in enetc_msg_psi_msix()), so new messages
arriving during processing do not generate additional CPU interrupts.
When enetc_msg_task() re-enables the interrupts at exit, the hardware
detects any MR bits that were set during execution and generates a new
interrupt, scheduling another task invocation.

This bounds the work per task invocation to at most num_vfs message
processing iterations, regardless of how aggressively VFs send messages.

Fixes: beb74ac878c8 ("enetc: Add vf to pf messaging support")
Signed-off-by: Wei Fang <wei.fang@nxp.com>
---
 .../net/ethernet/freescale/enetc/enetc_hw.h   |  1 +
 .../net/ethernet/freescale/enetc/enetc_msg.c  | 38 +++++++++----------
 2 files changed, 20 insertions(+), 19 deletions(-)

diff --git a/drivers/net/ethernet/freescale/enetc/enetc_hw.h b/drivers/net/ethernet/freescale/enetc/enetc_hw.h
index 662e4fbafb74..39b82faaf041 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_hw.h
+++ b/drivers/net/ethernet/freescale/enetc/enetc_hw.h
@@ -96,6 +96,7 @@ static inline u32 enetc_vsi_set_msize(u32 size)
 #define ENETC_PSIIER	0xa00
 #define ENETC_PSIIER_MR_MASK	GENMASK(2, 1)
 #define ENETC_PSIIDR	0xa08
+#define ENETC_PSIIDR_MR(n)	BIT((n) + 1) /* n = VSI index */
 #define ENETC_SITXIDR	0xa18
 #define ENETC_SIRXIDR	0xa28
 #define ENETC_SIMSIVR	0xa30
diff --git a/drivers/net/ethernet/freescale/enetc/enetc_msg.c b/drivers/net/ethernet/freescale/enetc/enetc_msg.c
index b4d7457097e6..39f057fe85c7 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_msg.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc_msg.c
@@ -32,32 +32,32 @@ static void enetc_msg_task(struct work_struct *work)
 {
 	struct enetc_pf *pf = container_of(work, struct enetc_pf, msg_task);
 	struct enetc_hw *hw = &pf->si->hw;
-	unsigned long mr_mask;
+	u32 mr_status;
 	int i;
 
-	for (;;) {
-		mr_mask = enetc_rd(hw, ENETC_PSIMSGRR) & ENETC_PSIMSGRR_MR_MASK;
-		if (!mr_mask) {
-			/* re-arm MR interrupts, w1c the IDR reg */
-			enetc_wr(hw, ENETC_PSIIDR, ENETC_PSIIER_MR_MASK);
-			enetc_msg_enable_mr_int(hw);
-			return;
-		}
+	mr_status = enetc_rd(hw, ENETC_PSIMSGRR) & ENETC_PSIMSGRR_MR_MASK;
+	if (!mr_status)
+		goto out;
 
-		for (i = 0; i < pf->num_vfs; i++) {
-			u32 psimsgrr;
-			u16 msg_code;
+	for (i = 0; i < pf->num_vfs; i++) {
+		u32 psimsgrr;
+		u16 msg_code;
+
+		if (!(ENETC_PSIMSGRR_MR(i) & mr_status))
+			continue;
 
-			if (!(ENETC_PSIMSGRR_MR(i) & mr_mask))
-				continue;
+		enetc_msg_handle_rxmsg(pf, i, &msg_code);
 
-			enetc_msg_handle_rxmsg(pf, i, &msg_code);
+		/* w1c to clear the corresponding VF MR bit */
+		enetc_wr(hw, ENETC_PSIIDR, ENETC_PSIIDR_MR(i));
 
-			psimsgrr = ENETC_SIMSGSR_SET_MC(msg_code);
-			psimsgrr |= ENETC_PSIMSGRR_MR(i); /* w1c */
-			enetc_wr(hw, ENETC_PSIMSGRR, psimsgrr);
-		}
+		psimsgrr = ENETC_SIMSGSR_SET_MC(msg_code);
+		psimsgrr |= ENETC_PSIMSGRR_MR(i); /* w1c */
+		enetc_wr(hw, ENETC_PSIMSGRR, psimsgrr);
 	}
+
+out:
+	enetc_msg_enable_mr_int(hw);
 }
 
 /* Init */
-- 
2.34.1

[PATCH v2 net 8/9] net: enetc: fix initialization order to prevent use of uninitialized resources

[Wei Fang]

Sashiko reported a potential issue in enetc_msg_psi_init() where the IRQ
handler is registered before DMA resources are fully initialized [1].

The current initialization sequence is:

  1. request_irq(enetc_msg_psi_msix)    <- IRQ handler registered
  2. INIT_WORK(&pf->msg_task, ...)      <- work_struct initialized
  3. enetc_msg_alloc_mbx()              <- mailbox DMA allocated

This ordering is unsafe because if a spurious interrupt or pending
interrupt from a previous device state fires immediately after
request_irq() returns, the registered ISR enetc_msg_psi_msix() will
execute and unconditionally call:

  schedule_work(&pf->msg_task)

At this point, pf->msg_task has not been initialized by INIT_WORK(), so
the work_struct contains garbage values in its internal linked list
pointers (work_struct->entry). Passing an uninitialized work_struct to
schedule_work() could corrupt the kernel's workqueue linked lists,
potentially leading to:

  - Kernel panic in __queue_work()
  - Memory corruption in workqueue data structures
  - System deadlock or undefined behavior

Additionally, even if the work_struct were initialized, the mailbox DMA
buffers (pf->rxmsg[]) may not yet be allocated when the work handler
enetc_msg_task() runs, resulting in NULL pointer dereference.

Fix by reordering the initialization sequence to ensure all resources are
properly initialized before the interrupt handler can execute:

  1. enetc_msg_alloc_mbx()              <- Allocate all mailboxes
  2. INIT_WORK(&pf->msg_task, ...)      <- Initialize work first
  3. request_irq(enetc_msg_psi_msix)    <- Register IRQ last
  4. Configure hardware & enable MR interrupts

This guarantees that when enetc_msg_psi_msix() runs:
  - pf->msg_task is properly initialized (safe for schedule_work)
  - pf->rxmsg[] buffers are allocated (safe for work handler access)
  - Hardware is configured appropriately

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>
---
 .../net/ethernet/freescale/enetc/enetc_msg.c  | 35 ++++++++++---------
 1 file changed, 18 insertions(+), 17 deletions(-)

diff --git a/drivers/net/ethernet/freescale/enetc/enetc_msg.c b/drivers/net/ethernet/freescale/enetc/enetc_msg.c
index 39f057fe85c7..a999f1e7817f 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_msg.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc_msg.c
@@ -109,6 +109,15 @@ int enetc_msg_psi_init(struct enetc_pf *pf)
 	struct enetc_si *si = pf->si;
 	int vector, i, err;
 
+	for (i = 0; i < pf->num_vfs; i++) {
+		err = enetc_msg_alloc_mbx(si, i);
+		if (err)
+			goto free_mbx;
+	}
+
+	/* initialize PSI mailbox */
+	INIT_WORK(&pf->msg_task, enetc_msg_task);
+
 	/* register message passing interrupt handler */
 	snprintf(pf->msg_int_name, sizeof(pf->msg_int_name), "%s-vfmsg",
 		 si->ndev->name);
@@ -117,32 +126,21 @@ int enetc_msg_psi_init(struct enetc_pf *pf)
 	if (err) {
 		dev_err(&si->pdev->dev,
 			"PSI messaging: request_irq() failed!\n");
-		return err;
+		goto free_mbx;
 	}
 
 	/* set one IRQ entry for PSI message receive notification (SI int) */
 	enetc_wr(&si->hw, ENETC_SIMSIVR, ENETC_SI_INT_IDX);
 
-	/* initialize PSI mailbox */
-	INIT_WORK(&pf->msg_task, enetc_msg_task);
-
-	for (i = 0; i < pf->num_vfs; i++) {
-		err = enetc_msg_alloc_mbx(si, i);
-		if (err)
-			goto err_init_mbx;
-	}
-
 	/* enable MR interrupts */
 	enetc_msg_enable_mr_int(&si->hw);
 
 	return 0;
 
-err_init_mbx:
+free_mbx:
 	for (i--; i >= 0; i--)
 		enetc_msg_free_mbx(si, i);
 
-	free_irq(vector, si);
-
 	return err;
 }
 
@@ -151,14 +149,17 @@ void enetc_msg_psi_free(struct enetc_pf *pf)
 	struct enetc_si *si = pf->si;
 	int i;
 
+	/* disable MR interrupts */
+	enetc_msg_disable_mr_int(&si->hw);
+
+	/* de-register message passing interrupt handler */
+	free_irq(pci_irq_vector(si->pdev, ENETC_SI_INT_IDX), si);
+
 	cancel_work_sync(&pf->msg_task);
 
-	/* disable MR interrupts */
+	/* MR interrupts may be re-enabled by workqueue */
 	enetc_msg_disable_mr_int(&si->hw);
 
 	for (i = 0; i < pf->num_vfs; i++)
 		enetc_msg_free_mbx(si, i);
-
-	/* de-register message passing interrupt handler */
-	free_irq(pci_irq_vector(si->pdev, ENETC_SI_INT_IDX), si);
 }
-- 
2.34.1

Re: [PATCH v2 net 8/9] net: enetc: fix initialization order to prevent use of uninitialized resources

[Harshitha Ramamurthy]

On Sun, May 17, 2026 at 8:09 PM Wei Fang <wei.fang@nxp.com> wrote:
>
> Sashiko reported a potential issue in enetc_msg_psi_init() where the IRQ
> handler is registered before DMA resources are fully initialized [1].
>
> The current initialization sequence is:
>
>   1. request_irq(enetc_msg_psi_msix)    <- IRQ handler registered
>   2. INIT_WORK(&pf->msg_task, ...)      <- work_struct initialized
>   3. enetc_msg_alloc_mbx()              <- mailbox DMA allocated
>
> This ordering is unsafe because if a spurious interrupt or pending
> interrupt from a previous device state fires immediately after
> request_irq() returns, the registered ISR enetc_msg_psi_msix() will
> execute and unconditionally call:
>
>   schedule_work(&pf->msg_task)
>
> At this point, pf->msg_task has not been initialized by INIT_WORK(), so
> the work_struct contains garbage values in its internal linked list
> pointers (work_struct->entry). Passing an uninitialized work_struct to
> schedule_work() could corrupt the kernel's workqueue linked lists,
> potentially leading to:
>
>   - Kernel panic in __queue_work()
>   - Memory corruption in workqueue data structures
>   - System deadlock or undefined behavior
>
> Additionally, even if the work_struct were initialized, the mailbox DMA
> buffers (pf->rxmsg[]) may not yet be allocated when the work handler
> enetc_msg_task() runs, resulting in NULL pointer dereference.
>
> Fix by reordering the initialization sequence to ensure all resources are
> properly initialized before the interrupt handler can execute:
>
>   1. enetc_msg_alloc_mbx()              <- Allocate all mailboxes
>   2. INIT_WORK(&pf->msg_task, ...)      <- Initialize work first
>   3. request_irq(enetc_msg_psi_msix)    <- Register IRQ last
>   4. Configure hardware & enable MR interrupts
>
> This guarantees that when enetc_msg_psi_msix() runs:
>   - pf->msg_task is properly initialized (safe for schedule_work)
>   - pf->rxmsg[] buffers are allocated (safe for work handler access)
>   - Hardware is configured appropriately
>
> 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>
> ---
>  .../net/ethernet/freescale/enetc/enetc_msg.c  | 35 ++++++++++---------
>  1 file changed, 18 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/net/ethernet/freescale/enetc/enetc_msg.c b/drivers/net/ethernet/freescale/enetc/enetc_msg.c
> index 39f057fe85c7..a999f1e7817f 100644
> --- a/drivers/net/ethernet/freescale/enetc/enetc_msg.c
> +++ b/drivers/net/ethernet/freescale/enetc/enetc_msg.c
> @@ -109,6 +109,15 @@ int enetc_msg_psi_init(struct enetc_pf *pf)
>         struct enetc_si *si = pf->si;
>         int vector, i, err;
>
> +       for (i = 0; i < pf->num_vfs; i++) {
> +               err = enetc_msg_alloc_mbx(si, i);
> +               if (err)
> +                       goto free_mbx;
> +       }
> +
> +       /* initialize PSI mailbox */
> +       INIT_WORK(&pf->msg_task, enetc_msg_task);
> +
>         /* register message passing interrupt handler */
>         snprintf(pf->msg_int_name, sizeof(pf->msg_int_name), "%s-vfmsg",
>                  si->ndev->name);
> @@ -117,32 +126,21 @@ int enetc_msg_psi_init(struct enetc_pf *pf)
>         if (err) {
>                 dev_err(&si->pdev->dev,
>                         "PSI messaging: request_irq() failed!\n");
> -               return err;
> +               goto free_mbx;
>         }
>
>         /* set one IRQ entry for PSI message receive notification (SI int) */
>         enetc_wr(&si->hw, ENETC_SIMSIVR, ENETC_SI_INT_IDX);
>
> -       /* initialize PSI mailbox */
> -       INIT_WORK(&pf->msg_task, enetc_msg_task);
> -
> -       for (i = 0; i < pf->num_vfs; i++) {
> -               err = enetc_msg_alloc_mbx(si, i);
> -               if (err)
> -                       goto err_init_mbx;
> -       }
> -
>         /* enable MR interrupts */
>         enetc_msg_enable_mr_int(&si->hw);
>
>         return 0;
>
> -err_init_mbx:
> +free_mbx:
>         for (i--; i >= 0; i--)
>                 enetc_msg_free_mbx(si, i);
>
> -       free_irq(vector, si);
> -
>         return err;
>  }
>
> @@ -151,14 +149,17 @@ void enetc_msg_psi_free(struct enetc_pf *pf)
>         struct enetc_si *si = pf->si;
>         int i;
>
> +       /* disable MR interrupts */
> +       enetc_msg_disable_mr_int(&si->hw);
> +
> +       /* de-register message passing interrupt handler */
> +       free_irq(pci_irq_vector(si->pdev, ENETC_SI_INT_IDX), si);
> +
>         cancel_work_sync(&pf->msg_task);
>
> -       /* disable MR interrupts */
> +       /* MR interrupts may be re-enabled by workqueue */
>         enetc_msg_disable_mr_int(&si->hw);
>
>         for (i = 0; i < pf->num_vfs; i++)
>                 enetc_msg_free_mbx(si, i);
> -
> -       /* de-register message passing interrupt handler */
> -       free_irq(pci_irq_vector(si->pdev, ENETC_SI_INT_IDX), si);

Code looks good to me but a nit: would be good if the change here in
enetc_msg_psi_free() is also called out in the commit message.

>  }
> --
> 2.34.1
>
>

[PATCH v2 net 9/9] net: enetc: avoid VF->PF mailbox timeout during SR-IOV teardown

[Wei Fang]

During SR-IOV teardown, enetc_msg_psi_free() disables the MR interrupt
before pci_disable_sriov() removes the VFs. If a VF sends a mailbox
message during this window, the PF cannot receive it, causing the VF to
timeout waiting for a reply.

Since the timeout occurs during SR-IOV teardown when the VF is about to
be removed anyway, it has no functional impact on operation. However,
more messages will be added in the future, some visible error logs may
confuse users. So fix it by calling pci_disable_sriov() first to remove
all VFs, then safely clean up the mailbox resources. This eliminates the
race window where VFs could send messages to an unresponsive PF.

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 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/freescale/enetc/enetc_pf.c b/drivers/net/ethernet/freescale/enetc/enetc_pf.c
index 8e11a023d516..3206b3daa1a0 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_pf.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc_pf.c
@@ -563,9 +563,9 @@ static int enetc_sriov_configure(struct pci_dev *pdev, int num_vfs)
 	int err;
 
 	if (!num_vfs) {
+		pci_disable_sriov(pdev);
 		enetc_msg_psi_free(pf);
 		pf->num_vfs = 0;
-		pci_disable_sriov(pdev);
 	} else {
 		pf->num_vfs = num_vfs;
 
-- 
2.34.1

Re: [PATCH v2 net 0/9] net: enetc: SR-IOV robustness and security fixes

[Harshitha Ramamurthy]

On Sun, May 17, 2026 at 8:03 PM Wei Fang <wei.fang@nxp.com> wrote:
>
> This patch series addresses a number of robustness, security, and
> correctness issues in the ENETC driver's SR-IOV subsystem, focusing
> primarily on the VF-to-PF mailbox communication path.
>
> The series can be grouped into the following categories:
>
> 1. DoS and security fixes:
>    - Prevent an unbounded loop DoS in the VF-to-PF message handler,
>      which could be triggered by a malicious or misbehaving VF.
>    - Fix a TOCTOU (Time-of-Check-Time-of-Use) race and add proper
>      validation of VF MAC addresses to prevent spoofing or invalid
>      configuration from being applied.
>
> 2. Race condition fixes:
>    - Fix a race condition in VF MAC address configuration that could
>      lead to inconsistent state between the VF request and PF
>      application.
>    - Fix a race condition during SR-IOV teardown that could cause
>      VF->PF mailbox operations to time out, resulting in unnecessary
>      errors during shutdown.
>
> 3. Memory safety fixes:
>    - Fix a DMA write to freed memory in enetc_msg_free_mbx(), which
>      could cause silent memory corruption or system instability.
>
> 4. Error handling and initialization fixes:
>    - Fix missing error code propagation when pf->vf_state allocation
>      fails, ensuring callers receive a proper errno instead of
>      succeeding silently.
>    - Fix incorrect mailbox message status values returned to VFs,
>      which could cause VFs to misinterpret PF responses.
>    - Fix initialization order to prevent the use of uninitialized
>      resources during driver probe, which could cause undefined
>      behavior on certain configurations.
>
> 5. Diagnostics improvement:
>    - Add rate limiting to VF mailbox error messages to prevent log
>      flooding in the presence of a misbehaving VF.
>
> These fixes improve the overall stability and security of the ENETC
> SR-IOV implementation, particularly in multi-tenant environments where
> VFs may be assigned to untrusted guests.
>
> ---
> v2:
> 1. Copy the message content from DMA memory to local memory
> 2. Patch 3 and 5 in v1 are merged into patch 8 in v2
> 3. Add more fix patches, such as patch 1, 2, 6 and 7
> v1 link: https://lore.kernel.org/imx/20260513103021.2190593-1-wei.fang@nxp.com/
> ---
>
> Wei Fang (9):
>   net: enetc: fix incorrect mailbox message status returned to VFs
>   net: enetc: fix missing error code when pf->vf_state allocation fails
>   net: enetc: add ratelimiting to VF mailbox error messages
>   net: enetc: fix TOCTOU race and validate VF MAC address
>   net: enetc: fix race condition in VF MAC address configuration
>   net: enetc: fix DMA write to freed memory in enetc_msg_free_mbx()
>   net: enetc: fix VF-to-PF message handler unbounded loop DoS
>   net: enetc: fix initialization order to prevent use of uninitialized
>     resources
>   net: enetc: avoid VF->PF mailbox timeout during SR-IOV teardown

Resending to the correct thread.

This v2 series LGTM. If the commit message for patch 8 is updated,
feel free to add:

Reviewed-by: Harshitha Ramamurthy <hramamurthy@google.com>

>
>  .../net/ethernet/freescale/enetc/enetc_hw.h   |  1 +
>  .../net/ethernet/freescale/enetc/enetc_msg.c  | 79 ++++++++++---------
>  .../net/ethernet/freescale/enetc/enetc_pf.c   | 75 +++++++++++++-----
>  .../net/ethernet/freescale/enetc/enetc_pf.h   |  1 +
>  4 files changed, 98 insertions(+), 58 deletions(-)
>
> --
> 2.34.1
>
>