Re: [PATCH v4 net-next 14/14] net: enetc: use kzalloc_flex() for enetc_psfp_gate allocation

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Inconsistent locking around the `epsfp` global state lists risks concurrent access issues, such as list corruption or use-after-free, particularly during stats polling.
--

--- Patch [14]: [PATCH v4 net-next 14/14] net: enetc: use kzalloc_flex() for enetc_psfp_gate allocation ---
commit 1354b34382c1b22bf61c564f93df2dfb8dea78a7
Author: Wei Fang <wei.fang@nxp.com>

net: enetc: use kzalloc_flex() for enetc_psfp_gate allocation
    
Replace the open-coded struct_size() + kzalloc() pattern with the
kzalloc_flex() helper when allocating struct enetc_psfp_gate. This
removes the intermediate entries_size local variable and makes the
allocation site more concise.

> diff --git a/drivers/net/ethernet/freescale/enetc/enetc_qos.c b/drivers/net/ethernet/freescale/enetc/enetc_qos.c
> index 7b17bca24f260..2aa0fcaafcd23 100644
> --- a/drivers/net/ethernet/freescale/enetc/enetc_qos.c
> +++ b/drivers/net/ethernet/freescale/enetc/enetc_qos.c

[ ... ]

> @@ -1242,8 +1241,7 @@ static int enetc_psfp_parse_clsflower(struct enetc_ndev_priv *priv,
>  		goto free_filter;
>  	}
>  
> -	entries_size = struct_size(sgi, entries, entryg->gate.num_entries);
> -	sgi = kzalloc(entries_size, GFP_KERNEL);
> +	sgi = kzalloc_flex(*sgi, entries, entryg->gate.num_entries);

[Severity: High]
This isn't a bug introduced by this patch, but is there a risk of list
corruption or a use-after-free due to inconsistent locking around the epsfp
global state lists?

Looking at enetc_psfp_destroy_clsflower(), it calls remove_one_chain()
without holding epsfp.psfp_lock:

enetc_qos.c:enetc_psfp_destroy_clsflower() {
    ...
	remove_one_chain(priv, filter);
    ...
}

Which then unlinks and frees the filter memory without list-protection
locks or RCU mechanisms:

enetc_qos.c:remove_one_chain() {
    ...
	hlist_del(&filter->node);
	kfree(filter);
    ...
}

If this destruction runs concurrently with stats polling, such as a user
executing tc filter show or the background stats timer, the reading path
can be actively iterating the list locklessly:

enetc_qos.c:enetc_get_stream_by_index() {
    ...
	hlist_for_each_entry(f, &epsfp.stream_list, node)
    ...
}

Could this concurrent hlist_del() and kfree() during a lockless
hlist_for_each_entry() traversal lead to a use-after-free or a kernel
panic?

>  	if (!sgi) {
>  		err = -ENOMEM;
>  		goto free_filter;

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