Re: [PATCH v2 5/8] watchdog: w83627hf_wdt: Add Super I/O configuration port as a platform device resource

Thank you for your contribution! Sashiko AI review found 1 potential issue(=
s) to consider:
- [Critical] Claiming the shared Super I/O configuration port as a static p=
latform device resource causes a Use-After-Free and breaks global mutual ex=
clusion upon module unload.
--

--- Patch [5]: [PATCH v2 5/8] watchdog: w83627hf_wdt: Add Super I/O configu=
ration port as a platform device resource ---
commit 7147d011852b779a7e376729ecb29c06b86e9282
Author: Paul Louvel <[email protected]>

watchdog: w83627hf_wdt: Add Super I/O configuration port as a platform devi=
ce resource

This commit changes the Super I/O configuration port address from a
global variable to a platform device resource. It uses
platform_device_register_resndata() to assign the IO resource during
module initialization.

> diff --git a/drivers/watchdog/w83627hf_wdt.c b/drivers/watchdog/w83627hf_=
wdt.c
> index 69d4230d8f6cc..a067b8ea6b289 100644
> --- a/drivers/watchdog/w83627hf_wdt.c
> +++ b/drivers/watchdog/w83627hf_wdt.c
[ ... ]
> @@ -594,8 +597,14 @@ static int __init wdt_init(void)
>  	if (ret)
>  		return ret;
> =20
> -	wdt_pdev =3D platform_device_register_data(NULL, wdt_ids[chip].name,
> -						 PLATFORM_DEVID_NONE, NULL, 0);
> +	res.name =3D "Super I/O port";
> +	res.flags =3D IORESOURCE_IO;
> +	res.start =3D sioaddr;
> +	res.end =3D sioaddr + 1;
> +
> +	wdt_pdev =3D platform_device_register_resndata(NULL, wdt_ids[chip].name,
> +						     PLATFORM_DEVID_NONE, &res,
> +						     1, NULL, 0);

[Severity: Critical]
Does claiming the shared Super I/O configuration port as a static platform=
=20
device resource cause a use-after-free regression and break mutual exclusio=
n=20
on module unload?

If this port is registered as a non-busy I/O resource, it becomes a=20
container node in the global ioport_resource tree. When another driver=20
calls request_muxed_region() for the same port, it might sleep on=20
muxed_resource_wait while holding a parent pointer to this container node.

If the wdt module is unloaded while that thread is sleeping,=20
platform_device_del() unlinks the container node and=20
platform_device_release() frees its memory. When the sleeping thread=20
wakes up, will it dereference the freed parent pointer in=20
__request_resource()?

Additionally, it appears that unlinking the container node orphans any=20
active child reservations from the tree. Could this allow concurrent=20
hardware access to the shared Super I/O port?

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