Re: [PATCH v3 1/1] can: mcp251xfd: Add ACPI device ID table for MCP251XFD

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Unconditional dereference of the pointer returned by spi_get_device_match_data() can cause a NULL pointer dereference.
--

commit 984f1d631588f571112e2f97f02bc97fcb1d8ec1
Author: guoqi0226 <guoqi0226@163.com>

can: mcp251xfd: Add ACPI device ID table for MCP251XFD

This patch adds an ACPI match table for the MCP251XFD CAN controller,
enabling driver binding on ACPI-enumerated SPI platforms.

> diff --git a/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c b/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c
> index 92a86083c8962..0cde98f51f797 100644
> --- a/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c
> +++ b/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c
[ ... ]
> @@ -2442,6 +2451,7 @@ static struct spi_driver mcp251xfd_driver = {
>  		.name = DEVICE_NAME,
>  		.pm = &mcp251xfd_pm_ops,
>  		.of_match_table = mcp251xfd_of_match,
> +		.acpi_match_table = ACPI_PTR(mcp251xfd_acpi_match),
>  	},
>  	.probe = mcp251xfd_probe,

[Severity: High]
This isn't a bug introduced by this patch, but there is a pre-existing issue
in mcp251xfd_probe() that might cause a kernel panic.

If the SPI device is bound to the driver manually via sysfs (for example, by
writing to the driver_override and bind files), spi_get_device_match_data()
can return NULL.

In mcp251xfd_probe(), the return value is dereferenced unconditionally:

static int mcp251xfd_probe(struct spi_device *spi)
{
        ...
        priv->devtype_data = *(struct mcp251xfd_devtype_data *)spi_get_device_match_data(spi);
        ...
}

Could we add a NULL check here that returns -ENODEV or falls back to a
default configuration to prevent the dereference?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260616091640.93275-1-guoqi0226@163.com?part=1