Re: [PATCH] HSI: hsi_char: Fix use-after-free on device removal

[Greg KH <gregkh@linuxfoundation.org>]

On Thu, Aug 27, 2026 at 04:43:08AM +0800, Shengzhuo Wei wrote:
> hsc_open() stores a pointer to a channel embedded in the hsc_client_data
> in file->private_data, but hsc_remove() frees the whole hsc_client_data
> right after cdev_del(). If the HSI client device is removed while a
> channel is open, the next access from the file descriptor (a read, an
> ioctl or the final close) dereferences freed memory:
> 
> CPU0                                CPU1
> hsc_remove                          hsc_read
>   cdev_del(&cl_data->cdev);           channel->cl->rx_cfg ...
>   kfree(cl_data);                     // use after free
> 
> Fix it by tracking the hsc_client_data with a kref: each open file
> descriptor takes a reference, and hsc_remove() drops the initial one,
> so the object is freed only after the last descriptor is closed.
> 
> Fixes: 4e69fc22753f ("HSI: hsi_char: Add HSI char device driver")
> Cc: stable@vger.kernel.org
> Signed-off-by: Shengzhuo Wei <me@cherr.cc>
> ---
>  drivers/hsi/clients/hsi_char.c | 14 +++++++++++++-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/hsi/clients/hsi_char.c b/drivers/hsi/clients/hsi_char.c
> index a31cc1466dd3ddf73762ce3d0213c96d64a190fd..479e5d6e94c8c03489464c4b39d81d697d104ce0 100644
> --- a/drivers/hsi/clients/hsi_char.c
> +++ b/drivers/hsi/clients/hsi_char.c
> @@ -96,6 +96,7 @@ struct hsc_channel {
>   * @usecnt: Use count for claiming the HSI port (mutex protected)
>   * @cl: Referece to the HSI client
>   * @channels: Array of channels accessible by the client
> + * @kref: Reference count for the client data lifetime
>   */
>  struct hsc_client_data {
>  	struct cdev		cdev;
> @@ -104,6 +105,7 @@ struct hsc_client_data {
>  	unsigned int		usecnt;
>  	struct hsi_client	*cl;
>  	struct hsc_channel	channels[HSC_DEVS];
> +	struct kref		kref;

You now have 2 reference counts for the same structure, which is not how
to handle this at all :(

Please either make the cdev be a pointer, or use the correct cdev api
for handling this type of common problem.

thanks,

greg k-h