Re: [PATCH v2 8/8] watchdog: w83627hf_wdt: Report all initialization failures in probe

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Unchecked dereferences of `id` and `pdata` in probe can lead to a kernel Oops.
--

--- Patch [8]: [PATCH v2 8/8] watchdog: w83627hf_wdt: Report all initialization failures in probe ---
commit 0129cf43f51e4968c683b359d971eaa0c48a6846
Author: Paul Louvel <paul.louvel@bootlin.com>

watchdog: w83627hf_wdt: Report all initialization failures in probe
    
The driver currently logs an error only if the chip initialization
fails. Extend the error reporting to all failure paths in probe to
improve diagnostics.

> diff --git a/drivers/watchdog/w83627hf_wdt.c b/drivers/watchdog/w83627hf_wdt.c
> index 2957364485ebf..7b50865ae8248 100644
> --- a/drivers/watchdog/w83627hf_wdt.c
> +++ b/drivers/watchdog/w83627hf_wdt.c
> @@ -485,7 +485,8 @@ static int wdt_probe(struct platform_device *pdev)
>  
>  	res = platform_get_resource(pdev, IORESOURCE_IO, 0);
>  	if (!res)
> -		return -ENXIO;
> +		return dev_err_probe(dev, -ENXIO,
> +				     "failed to get I/O resource\n");

[Severity: High]
Could the dereferences of id and pdata earlier in this function lead to a
kernel Oops?

If a user binds a device to this driver via sysfs (for example, using
driver_override or bind), platform_get_device_id(pdev) will return NULL
because the device ID does not match any entry in the driver's id_table. 

This leads to a NULL pointer dereference when initializing chip:

wdt_probe()
    const struct platform_device_id *id = platform_get_device_id(pdev);
    ...
    enum chips chip = id->driver_data;

Additionally, binding a platform device this way leaves
pdev->dev.platform_data as NULL, causing a subsequent NULL pointer
dereference when accessing pdata:

wdt_probe()
    const struct wdt_pdata *pdata = pdev->dev.platform_data;
    ...
    data->siocfg_enter = pdata->siocfg_enter;

Since this can be triggered from userspace by a user with privileges to
write to sysfs, could this be used to panic the kernel?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260726-w83627hf_wdt-improvements-v2-0-3645a2a6c022@bootlin.com?part=8