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

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 initializa=
tion failures in probe ---
commit 0129cf43f51e4968c683b359d971eaa0c48a6846
Author: Paul Louvel <[email protected]>

watchdog: w83627hf_wdt: Report all initialization failures in probe
   =20
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)
> =20
>  	res =3D 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.=20

This leads to a NULL pointer dereference when initializing chip:

wdt_probe()
    const struct platform_device_id *id =3D platform_get_device_id(pdev);
    ...
    enum chips chip =3D 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 =3D pdev->dev.platform_data;
    ...
    data->siocfg_enter =3D 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?

[ ... ]

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260726-w83627hf_w=
[email protected]?part=3D8