Re: [PATCH net-next 03/15] net: enetc: add link status message support to PF driver

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] The `msg_lock` mutex is used uninitialized if the device does not support SR-IOV or if the PF initializes with 0 VFs, leading to a kernel panic or lockdep splat on link up/down.
- [High] A malicious or unresponsive VF can stall the PF's shared message handler for 200ms per request, causing a Denial of Service (DoS).
- [Medium] Data race on `pf->link_status_ms_mask` during SR-IOV teardown causes a 200ms timeout on concurrent link state changes.
--

commit 7d8f9f9cc2f3db8a098f8342c6d804d1aeb36a72
Author: Wei Fang <wei.fang@nxp.com>
Date:   Fri Jun 5 06:55:38 2026 +0000

net: enetc: add link status message support to PF driver

Add link status message support to the PF driver using three command IDs
under message class 0x80 (ENETC_MSG_CLASS_ID_LINK_STATUS).

> diff --git a/drivers/net/ethernet/freescale/enetc/enetc_pf_common.c b/drivers/net/ethernet/freescale/enetc/enetc_pf_common.c
> --- a/drivers/net/ethernet/freescale/enetc/enetc_pf_common.c
> +++ b/drivers/net/ethernet/freescale/enetc/enetc_pf_common.c
> @@ -458,6 +458,8 @@ int enetc_init_sriov_resources(struct enetc_pf *pf)
>  	for (int i = 0; i < pf->total_vfs; i++)
>  		mutex_init(&pf->vf_state[i].lock);
>  
> +	mutex_init(&pf->msg_lock);
> +
>  	return 0;
>  }

[Severity: High]
If the device does not support SR-IOV or total_vfs is 0,
enetc_init_sriov_resources() returns early:

        pf->total_vfs = pci_sriov_get_totalvfs(pf->si->pdev);
        if (!pf->total_vfs)
                return 0;

This skips the mutex_init() for msg_lock.

However, the phylink callbacks enetc4_pl_mac_link_up() and
enetc4_pl_mac_link_down() unconditionally call enetc_pf_notify_vf_link_up()
and enetc_pf_notify_vf_link_down().

These functions eventually reach enetc_pf_notify_vf_link_status(), which
attempts to acquire this uninitialized lock:

enetc_pf_notify_vf_link_status()
    mutex_lock(&pf->msg_lock);

Could this cause a lockdep warning or a crash when the device link comes
up or goes down and total_vfs is 0?

> diff --git a/drivers/net/ethernet/freescale/enetc/enetc_msg.c b/drivers/net/ethernet/freescale/enetc/enetc_msg.c
> --- a/drivers/net/ethernet/freescale/enetc/enetc_msg.c
> +++ b/drivers/net/ethernet/freescale/enetc/enetc_msg.c
[ ... ]
> +static int enetc_pf_send_msg(struct enetc_pf *pf, u32 msg_code, u16 ms_mask)
> +{
> +	struct enetc_si *si = pf->si;
> +	u32 val;
> +
> +	enetc_wr(&si->hw, ENETC_PSIMSGSR,
> +		 FIELD_PREP(PSIMSGSR_MC, msg_code) | ms_mask);
> +
> +	return read_poll_timeout(enetc_rd, val, !(val & ms_mask), 1000,
> +				 200000, false, &si->hw, ENETC_PSIMSGSR);
> +}
> +
> +static void enetc_msg_notify_vf_link_status(struct enetc_pf *pf, u16 ms_mask,
> +					    bool link_up)
> +{
[ ... ]
> +	if (enetc_pf_send_msg(pf, pf_msg, ms_mask))
> +		dev_err_ratelimited(&pf->si->pdev->dev,
> +				    "PF notifies link status failed\n");
> +}

[Severity: High]
If a VF is malicious, crashed, or improperly configured and fails to clear
its bit in ENETC_PSIMSGSR, enetc_pf_send_msg() will block the phylink worker
thread for its maximum 200ms polling timeout.

Because enetc_msg_notify_vf_link_status() only logs an error and does not
remove the unresponsive VF from pf->link_status_ms_mask, won't every
subsequent link state change also incur this 200ms stall?

Additionally, a malicious VF could spam ENETC_MSG_REGISTER_LINK_CHANGE_NOTIFIER
messages, forcing the PF to repeatedly call enetc_pf_send_msg() while holding
pf->msg_lock. Could this stall the shared msg_task workqueue and starve
other VFs?

> @@ -361,6 +471,7 @@ int enetc_sriov_configure(struct pci_dev *pdev, int num_vfs)
>  	if (!num_vfs) {
>  		pci_disable_sriov(pdev);
>  		enetc_msg_psi_free(pf);
> +		pf->link_status_ms_mask = 0;
>  		pf->num_vfs = 0;
>  	} else {

[Severity: Medium]
When disabling SR-IOV, pf->link_status_ms_mask is cleared outside of
pf->msg_lock and after the VFs have been disabled via pci_disable_sriov().

If a physical link state change occurs concurrently, could
enetc_pf_notify_vf_link_status() acquire the lock, observe a stale non-zero
ms_mask, and attempt to notify destroyed VFs?

Since the VFs are no longer active, they wouldn't clear their bits, causing
enetc_pf_send_msg() to inevitably timeout after 200ms. Should this mask be
cleared under the msg_lock before disabling SR-IOV?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260605065550.3038579-1-wei.fang@oss.nxp.com?part=3