Re: [PATCH] watchdog: pcwd_usb: keep device alive for open files

[Guenter Roeck]

On 8/5/26 03:29, Qing Ming wrote:
> misc_deregister() prevents new opens but does not close existing watchdog
> or temperature files. Both file-operation tables continue to use the global
> usb_pcwd_device after usb_pcwd_disconnect() frees the private object.
>
> Keeping a temperature file open across USB disconnect and then reading it
> therefore accesses freed memory. KASAN reports:
>
>    BUG: KASAN: slab-use-after-free in usb_pcwd_send_command+0x4f/0x480
>    usb_pcwd_get_temperature+0x71/0xd0
>    usb_pcwd_temperature_read+0x5e/0x90
>
> The object was allocated by usb_pcwd_probe() and freed by
> usb_pcwd_disconnect().
>
> Store the device object in file->private_data and hold a reference for
> every successful watchdog or temperature open. Use disconnect_mutex only
> while stabilizing the global pointer and taking that reference, avoiding a
> lock inversion with miscdevice teardown. Serialize command submission with
> disconnect and quiesce the device if probe fails after the temperature
> miscdevice becomes visible. Reject commands after the device is gone and
> release the object after the final file is closed. Hold the usb_device
> reference until the private object and its USB allocations are released.
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Cc: stable@xxxxxxxxxxxxxxx
> Signed-off-by: Qing Ming <a0yami@xxxxxxxxxxx>

This driver was introduced when the watchdog subsystem did not exist.
I am not going to touch it. Many of its problems (and there are many,
as Sashiko points out) can and should be fixed by converting it to use
the watchdog subsystem. On top of that, I consider disconnecting a USB
watchdog from a running system is out of scope for an urgent fix.
This leads to the question: how does one even do that ? It also requires
disconnecting the reset wire. Is this even real hardware ?

If you do have hardware, I would suggest to convert the driver to use
the watchdog subsystem.

Thanks,
Guenter