Re: [PATCH RESEND v4 net-next 02/14] net: enetc: extract common helpers for MAC hash filter configuration

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] In `enetc_sync_mac_filters`, falling back to hash table (HT) filtering after a failed exact match (EM) filter insertion reads corrupted data from a union, configuring an invalid hardware filter.
--

--- Patch [2]: [PATCH RESEND v4 net-next 02/14] net: enetc: extract common helpers for MAC hash filter configuration ---
commit 9f93708413c38f9e209ca579bcb44ec6059cbebf
Author: Wei Fang <wei.fang@nxp.com>

net: enetc: extract common helpers for MAC hash filter configuration

This commit extracts MAC hash filter configuration helpers to share code
between the ENETC v1 and v4 drivers. It introduces enetc_set_si_uc_hash_filter
and enetc_set_si_mc_hash_filter to replace duplicated hardware revision
specific implementations.

> diff --git a/drivers/net/ethernet/freescale/enetc/enetc_pf.c b/drivers/net/ethernet/freescale/enetc/enetc_pf.c
> index a97d2e2dd07b7..db2a800a7aaf0 100644
> --- a/drivers/net/ethernet/freescale/enetc/enetc_pf.c
> +++ b/drivers/net/ethernet/freescale/enetc/enetc_pf.c
[ ... ]
> @@ -135,7 +108,7 @@ static void enetc_sync_mac_filters(struct enetc_pf *pf)
>  		if (em) {
>  			int err;
>  
> -			enetc_clear_mac_ht_flt(si, 0, UC);
> +			enetc_set_si_uc_hash_filter(si, 0, 0);
>  
>  			err = enetc_set_mac_flt_entry(si, pos, f->mac_addr,
>  						      BIT(0));
> @@ -147,11 +120,15 @@ static void enetc_sync_mac_filters(struct enetc_pf *pf)
>  				 err);
>  		}
>  
> +		bitmap_to_arr64(&hash, f->mac_hash_table,
> +				ENETC_MADDR_HASH_TBL_SZ);

[Severity: High]
This is a pre-existing issue, but does the fallback to hash table filtering
here read corrupted data?

In struct enetc_mac_filter, mac_addr and mac_hash_table share the same
memory space inside a union. When configuring an exact match filter, only
mac_addr is populated.

If enetc_set_mac_flt_entry() fails, the code continues to this fallback path
and reads from f->mac_hash_table. Since it is a union, wouldn't this just
read the raw bytes of the MAC address (along with uninitialized padding)
and interpret it as a hash bitmask?

Could this misconfigure the hardware MAC hash filter and lead to incorrect
functional behavior and silent packet drops for unicast filtering?

>  		/* hash table filter, clear EM filter for UC entries */
> -		if (i == UC)
> +		if (i == UC) {
>  			enetc_clear_mac_flt_entry(si, pos);
> -
> -		enetc_set_mac_ht_flt(si, 0, i, *f->mac_hash_table);
> +			enetc_set_si_uc_hash_filter(si, 0, hash);
> +		} else {
> +			enetc_set_si_mc_hash_filter(si, 0, hash);
> +		}
>  	}
>  }

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