Re: [PATCH net-next v5 06/13] net: lan966x: add FDMA ops dispatch for PCIe support

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Race condition leading to NULL pointer dereference, and improper error cleanup causing active NAPI deletion during probe.
--

commit 451c636b2ada8ed9e0353b85f81b6fd1d9682b69
Author: Daniel Machon <daniel.machon@microchip.com>

net: lan966x: add FDMA ops dispatch for PCIe support

This commit introduces an ops table for FDMA operations to support
different implementations for platform and PCIe instances. It plumbs
the various FDMA functions through this new ops structure.

> diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_main.c b/drivers/net/ethernet/microchip/lan966x/lan966x_main.c
> --- a/drivers/net/ethernet/microchip/lan966x/lan966x_main.c
> +++ b/drivers/net/ethernet/microchip/lan966x/lan966x_main.c

[ ... ]

> @@ -1234,7 +1249,7 @@ static int lan966x_probe(struct platform_device *pdev)
>  	if (err)
>  		goto cleanup_fdb;
>  
> -	err = lan966x_fdma_init(lan966x);
> +	err = lan966x->ops->fdma_init(lan966x);
>  	if (err)
>  		goto cleanup_ptp;

[Severity: High]
This isn't a bug introduced by this patch, but looking at the probe
sequence, could this late initialization of FDMA lead to a NULL pointer
dereference?

Earlier in lan966x_probe(), the ports are initialized and
lan966x_fdma_netdev_init() is called, which in turn calls napi_enable().
The FDMA interrupt is also requested early. 

Since the FDMA queue backing memory isn't allocated until
lan966x->ops->fdma_init() is called here, what happens if an interrupt fires
before this point? It appears the interrupt handler could schedule the NAPI
instance, and the poll routine would execute fdma_has_frames(), which then
dereferences the unallocated fdma->dcbs pointer.

>  
> @@ -1247,7 +1262,7 @@ static int lan966x_probe(struct platform_device *pdev)
>  	return 0;
>  
>  cleanup_fdma:
> -	lan966x_fdma_deinit(lan966x);
> +	lan966x->ops->fdma_deinit(lan966x);
>  
>  cleanup_ptp:
>  	lan966x_ptp_deinit(lan966x);

[Severity: High]
This is a pre-existing issue, but does skipping fdma_deinit() here leave
the NAPI instance enabled during the rest of the error cleanup?

When jumping to cleanup_ptp, it skips the fdma_deinit() call which would
normally disable NAPI. The cleanup path eventually reaches
lan966x_fdma_netdev_deinit(), which calls netif_napi_del() on the
still-enabled NAPI structure. 

Does this create a use-after-free vulnerability in softnet_data.poll_list by
deleting an active NAPI structure?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260520-lan966x-pci-fdma-v5-0-ca56197ae05b@microchip.com?part=6