mirror of
https://github.com/torvalds/linux.git
synced 2026-05-27 08:33:17 +02:00
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: beb74ac878 ("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>
This commit is contained in:
parent
c666fa632f
commit
f262f5d893
|
|
@ -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);
|
||||
|
|
|
|||
|
|
@ -14,6 +14,7 @@ enum enetc_vf_flags {
|
|||
};
|
||||
|
||||
struct enetc_vf_state {
|
||||
struct mutex lock; /* Prevent concurrent access */
|
||||
enum enetc_vf_flags flags;
|
||||
};
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user