Re: [PATCH 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 1 potential issue(s) to consider:
- [Critical] State leakage of VF configuration flags across SR-IOV disable/enable cycles leading to privilege escalation.
--

commit 4b3358f3b481a101e7878efe2d4cc289110ff9db
Author: Wei Fang <wei.fang@nxp.com>
net: enetc: restore VF MAC promiscuous mode after FLR for ENETC v4

This commit adds tracking for VF MAC promiscuous mode to mitigate a security
vulnerability where a VF Function Level Reset (FLR) defaults to enabling
promiscuous mode. It introduces a vf_flr_handler callback to restore the
hardware state based on PF-managed policies.

> diff --git a/drivers/net/ethernet/freescale/enetc/enetc4_pf.c b/drivers/net/ethernet/freescale/enetc/enetc4_pf.c
> index 2e081a59154e1..15c8b704b2b75 100644
> --- a/drivers/net/ethernet/freescale/enetc/enetc4_pf.c
> +++ b/drivers/net/ethernet/freescale/enetc/enetc4_pf.c

[ ... ]

> @@ -283,11 +283,32 @@ static void enetc4_pf_set_mac_filter(struct enetc_pf *pf, int type)
>  		enetc4_pf_set_mac_hash_filter(pf, ENETC_MAC_FILTER_TYPE_MC);
>  }
>  
> +static void enetc4_pf_vf_flr_handler(struct enetc_pf *pf, int vf_id)
> +{
> +	struct enetc_hw *hw = &pf->si->hw;
> +	struct enetc_vf_state *vf_state;
> +	bool uc_promisc, mc_promisc;
> +
> +	vf_state = &pf->vf_state[vf_id];
> +	mutex_lock(&vf_state->lock);
> +
> +	uc_promisc = !!(vf_state->flags & ENETC_VF_FLAG_UC_PROMISC);
> +	mc_promisc = !!(vf_state->flags & ENETC_VF_FLAG_MC_PROMISC);
> +
> +	mutex_lock(&pf->msg_lock);
> +	enetc4_pf_set_si_mac_promisc(hw, vf_id + 1, UC, uc_promisc);

[Severity: Critical]
Does this introduce a privilege escalation due to state leakage across SR-IOV
disable/enable cycles?

When SR-IOV is disabled, enetc_sriov_configure() drops pf->num_vfs but does 
not appear to clear the pf->vf_state array. As a result, the state from the 
previous session leaks into the next session.

If a previously trusted VF had these flags set, a newly created untrusted VF 
would inherit them. The untrusted VM could then deliberately trigger a 
Function Level Reset (FLR), causing this handler to explicitly restore the 
hardware to promiscuous mode based on the leaked flags:

enetc4_pf_vf_flr_handler()
    uc_promisc = !!(vf_state->flags & ENETC_VF_FLAG_UC_PROMISC);
    ...
    enetc4_pf_set_si_mac_promisc(hw, vf_id + 1, UC, uc_promisc);

Could this allow an untrusted VM to sniff network traffic destined for other 
VMs or the host? Should pf->vf_state be reinitialized when SR-IOV is 
disabled or enabled?

> +	enetc4_pf_set_si_mac_promisc(hw, vf_id + 1, MC, mc_promisc);
> +	mutex_unlock(&pf->msg_lock);
> +
> +	mutex_unlock(&vf_state->lock);
> +}

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