Re: [PATCH v2 net-next 11/15] net: enetc: restore VF MAC promiscuous mode after FLR for ENETC v4

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Untrusted VFs retain expansive multicast hash filters when trust is revoked.
- [Low] Comment logic inversion regarding PF-set flags in `enetc_msg_psi_free`.
--

commit 39a4c53c34896221262cf925fccff9665bc34780
Author: Wei Fang <wei.fang@nxp.com>

net: enetc: restore VF MAC promiscuous mode after FLR for ENETC v4

This commit addresses a security vulnerability on ENETC v4 where a VF FLR
resets the MAC promiscuous mode to enabled. The patch tracks the PF-managed
promiscuous state, updates it on VF requests and trust revocation, and adds
an FLR handler to restore the tracked state after an FLR.

> 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
[ ... ]
> @@ -725,8 +765,21 @@ static void enetc_msg_psi_free(struct enetc_pf *pf)
>  	/* PSIIER interrupts may be re-enabled by workqueue */
>  	enetc_disable_psiier_interrupts(pf);
>  
> -	for (i = 0; i < pf->num_vfs; i++)
> +	for (i = 0; i < pf->num_vfs; i++) {
> +		struct enetc_vf_state *vf_state = &pf->vf_state[i];
> +
>  		enetc_msg_free_mbx(si, i);
> +
> +		/* VF may set these flags by mailbox messages, so need to
> +		 * clear these flags when enetc_msg_psi_free() is called.
> +		 * Flags set by PF are cleared, because these flags are
> +		 * unrelated to whether SR-IOV is enabled or disabled.
> +		 */

[Severity: Low]
This isn't a bug, but should the comment say "Flags set by PF are NOT
cleared"?

The bitwise AND operation below exclusively clears the promiscuous flags
set by the VF while preserving flags set by the PF, such as
ENETC_VF_FLAG_TRUSTED.

> +		mutex_lock(&vf_state->lock);
> +		vf_state->flags &= ~(ENETC_VF_FLAG_UC_PROMISC |
> +				     ENETC_VF_FLAG_MC_PROMISC);
> +		mutex_unlock(&vf_state->lock);
> +	}
>  }

> 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
[ ... ]
> @@ -480,7 +480,9 @@ int enetc_pf_set_vf_trust(struct net_device *ndev, int vf, bool setting)
>  	if (setting) {
>  		vf_state->flags |= ENETC_VF_FLAG_TRUSTED;
>  	} else {
> -		vf_state->flags &= ~ENETC_VF_FLAG_TRUSTED;
> +		vf_state->flags &= ~(ENETC_VF_FLAG_TRUSTED |
> +				     ENETC_VF_FLAG_UC_PROMISC |
> +				     ENETC_VF_FLAG_MC_PROMISC);
>  
>  		/* Clear unicast hash filter and disable MAC promiscuous modes
>  		 * if the VF is untrusted.
>  		 */

[Severity: High]
Does this leave untrusted VFs with an expansive multicast hash filter when
trust is revoked?

When a VF is trusted, it can set a broad 64-bit multicast hash filter,
while untrusted VFs are restricted to 8 bits. When an administrator revokes
trust, the PF clears the unicast hash filter and disables MAC promiscuous
modes, but it doesn't appear to clear the multicast hash filter here.

Could a previously trusted VF retain its expansive multicast hash filter
after trust is revoked, bypassing the security policy?

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