Re: [PATCH 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 3 potential issue(s) to consider:

New issues:
- [High] The patch dynamically allocates the netdevice TX/RX queues based on hardware-provided `si->num_tx_rings`, but the interrupt handlers still use the hardcoded `ENETC_MAX_NUM_TXQS` (8) limit, causing unhandled interrupts and hanging queues for any TX rings >= 8.

Pre-existing issues:
- [High] Missing bounds check on hardware-provided queue counts leads to out-of-bounds writes on the fixed-size `tx_ring` and `rx_ring` static arrays.
- [High] The `int_vector` array has a hardcoded size of 6, but is indexed by a value bounded only by `num_online_cpus()`, causing out-of-bounds writes on systems with > 6 CPUs.
--

commit 79626f31ed7ba6f966e47382436575165e9f1b3d
Author: Wei Fang <wei.fang@nxp.com>
Subject: net: enetc: use alloc_etherdev_mqs() to create netdev for VF driver

This commit changes the netdev creation in the ENETC VF driver to use
alloc_etherdev_mqs(). This allows setting the TX and RX queue counts
independently based on the hardware capabilities (si->num_tx_rings and
si->num_rx_rings) rather than using a hardcoded ENETC_MAX_NUM_TXQS limit.

> diff --git a/drivers/net/ethernet/freescale/enetc/enetc_vf.c b/drivers/net/ethernet/freescale/enetc/enetc_vf.c
> --- a/drivers/net/ethernet/freescale/enetc/enetc_vf.c
> +++ b/drivers/net/ethernet/freescale/enetc/enetc_vf.c
> @@ -317,7 +317,8 @@ static int enetc_vf_probe(struct pci_dev *pdev,
>  
>  	enetc_get_si_caps(si);
>  

[Severity: High]
This is a pre-existing issue, but does enetc_get_si_caps() bound the ring
counts read from hardware?

Looking at enetc_get_si_caps() in enetc.c, si->num_tx_rings and 
si->num_rx_rings are read directly from hardware and bounded only by 0xff.
The arrays priv->tx_ring and priv->rx_ring are statically sized to 16 in
struct enetc_ndev_priv.

If the hardware provides a ring count greater than 16, could this cause an
out-of-bounds write when enetc_int_vector_init() initializes these arrays?


[Severity: High]
This is also a pre-existing issue, but is the int_vector array size safe
when running on a system with more than 6 CPUs?

In enetc_init_si_rings_params(), the driver bounds the interrupt vector
count by the number of online CPUs:

    priv->num_rx_rings = min_t(int, cpus, si->num_rx_rings);
    priv->bdr_int_num = priv->num_rx_rings;

However, the int_vector array in struct enetc_ndev_priv is statically
sized to ENETC_MAX_BDR_INT (6). Could this lead to an out-of-bounds write
in enetc_int_vector_init() if the system has more than 6 CPUs and the
hardware provides more than 6 RX rings?

> -	ndev = alloc_etherdev_mq(sizeof(*priv), ENETC_MAX_NUM_TXQS);
> +	ndev = alloc_etherdev_mqs(sizeof(*priv), si->num_tx_rings,
> +				  si->num_rx_rings);

[Severity: High]
By replacing ENETC_MAX_NUM_TXQS with si->num_tx_rings here, could this
cause queues to hang if the hardware provides more than 8 TX rings?

Looking at the interrupt handling in enetc.c, both enetc_msix() and
enetc_poll() still use the hardcoded ENETC_MAX_NUM_TXQS (8) limit when
iterating over the rings map:

enetc_poll() {
    ...
    for_each_set_bit(i, &v->tx_rings_map, ENETC_MAX_NUM_TXQS) {
        ...
    }
}

If a VF is initialized with more than 8 TX rings, will the interrupts for
queues 8 and above remain masked at the end of the NAPI poll loop,
preventing further TX completions?

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

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