Re: [PATCH RESEND v4 net-next 13/14] net: enetc: use alloc_etherdev_mqs() to create netdev for VF driver

[sashiko-bot@kernel.org]

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

New issues:
- [Low] Passing 0 to alloc_etherdev_mqs() triggers a pr_err() inside the networking core if the hardware reports 0 rings.

Pre-existing issues:
- [Critical] Hardware-provided ring counts are not bounded against driver static array sizes, causing out-of-bounds writes.
--

--- Patch [13]: [PATCH RESEND v4 net-next 13/14] net: enetc: use alloc_etherdev_mqs() to create netdev for VF driver ---
commit 79eef0d032f82d691851f474deed33cca36dd548
Author: Wei Fang <wei.fang@nxp.com>

net: enetc: use alloc_etherdev_mqs() to create netdev for VF driver

This commit changes the VF driver to use alloc_etherdev_mqs() instead of
alloc_etherdev_mq(), allowing TX and RX queue counts to be set independently
based on the actual hardware capabilities up to ENETC_MAX_NUM_TXQS.

> diff --git a/drivers/net/ethernet/freescale/enetc/enetc_vf.c b/drivers/net/ethernet/freescale/enetc/enetc_vf.c
> index 9cdb0a4d6bafb..7dcb4a0246f52 100644
> --- a/drivers/net/ethernet/freescale/enetc/enetc_vf.c
> +++ b/drivers/net/ethernet/freescale/enetc/enetc_vf.c
> @@ -317,7 +317,14 @@ static int enetc_vf_probe(struct pci_dev *pdev,
>  
>  	enetc_get_si_caps(si);
>  
> -	ndev = alloc_etherdev_mq(sizeof(*priv), ENETC_MAX_NUM_TXQS);
> +	/* Currently, the supported SoCs have a max of 6 CPUs and the VFs
> +	 * have less than 6 RX/TX rings. So no issues for these supported
> +	 * SoCs, but for future SoCs which have more CPUs or more TX/RX
> +	 * rings, all the related logic needs to be improved.
> +	 */
> +	ndev = alloc_etherdev_mqs(sizeof(*priv),
> +				  min(si->num_tx_rings, ENETC_MAX_NUM_TXQS),
> +				  min(si->num_rx_rings, ENETC_MAX_NUM_TXQS));

[Severity: Low]
Does this code handle the case where the hardware reports 0 rings?

If si->num_tx_rings or si->num_rx_rings is 0, this passes 0 to
alloc_etherdev_mqs(), which triggers a "Unable to allocate device with zero
queues" pr_err() in the network core and returns NULL. The previous hardcoded
ENETC_MAX_NUM_TXQS guaranteed a valid count.

Should there be a check to ensure the ring counts are at least 1?

[Severity: Critical]
This is a pre-existing issue, but is it possible for the hardware to report
ring counts that exceed the internal array sizes, causing an out-of-bounds
write?

Looking at enetc_init_si_rings_params(), the hardware-provided ring counts
are assigned without validating them against the internal array bounds:

drivers/net/ethernet/freescale/enetc/enetc.c:enetc_init_si_rings_params() {
	...
	priv->num_tx_rings = si->num_tx_rings;
	priv->bdr_int_num = priv->num_rx_rings;
	...
}

Subsequently, enetc_alloc_msix() loops over these values and writes to the
statically sized arrays in enetc_int_vector_init():

drivers/net/ethernet/freescale/enetc/enetc.c:enetc_int_vector_init() {
	...
	priv->tx_ring[idx] = bdr;
	...
}

A malicious or misconfigured PCI hypervisor or Physical Function (PF) could
supply arbitrary values to the Virtual Function (VF) driver. If the hardware
reports huge ring counts, this causes a buffer overflow on the heap when
writing to priv->int_vector (size 6) and priv->tx_ring (size 16), which could
lead to a panic or arbitrary code execution.

Could these values be strictly bounded against the array sizes during probe?

>  	if (!ndev) {
>  		err = -ENOMEM;
>  		dev_err(&pdev->dev, "netdev creation failed\n");

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