Re: [PATCH] input: sur40: fix use-after-free in disconnect

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] Unkillable deadlock in `sur40_stop_streaming` during disconnect.
- [High] Hang in VIDIOC_DQBUF or poll due to missing queue abort in disconnect.
--

commit 8870e5b6bd950af7749d533c844ef1b23fd8c7bb
Author: Pei Xiao <xiaopei01@kylinos.cn>
Date:   Wed Aug 26 03:42:39 2026 +0000

    input: sur40: fix use-after-free in disconnect

This commit fixes a use-after-free in sur40_disconnect() by replacing the
direct kfree() with a new vdev->release callback. This ensures the sur40_state
structure is only freed when the last userspace reference is released. It also
adjusts the error paths in sur40_probe() to prevent accessing freed memory.

Reported-by: syzbot+4a6e6173b1fc7916e950@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/all/6a8e44ca.dbb3a75c.7844.002f.GAE@google.com/
Cc: stable@vger.kernel.org

> diff --git a/drivers/input/touchscreen/sur40.c b/drivers/input/touchscreen/sur40.c
> index 09d8c5f8d09fc..2d93234cc86a0 100644
> --- a/drivers/input/touchscreen/sur40.c
> +++ b/drivers/input/touchscreen/sur40.c
[ ... ]
> @@ -820,19 +824,23 @@ static int sur40_probe(struct usb_interface *interface,
>  	return error;
>  }
>  
> -/* Unregister device & clean up. */
> +static void sur40_video_release(struct video_device *vdev)
> +{
[ ... ]
> +}
> +
>  static void sur40_disconnect(struct usb_interface *interface)
>  {
>  	struct sur40_state *sur40 = usb_get_intfdata(interface);
>  
>  	input_unregister_device(sur40->input);
>  
> -	v4l2_ctrl_handler_free(&sur40->hdl);
>  	video_unregister_device(&sur40->vdev);

[Severity: High]
This isn't a bug introduced by this patch, but is it possible that
unregistering the video device without aborting the pending V4L2 queue
leaves blocked ioctls waiting forever?

When the device is disconnected, video_unregister_device() is called here
without first waking up q->done_wq waiters with -EIO (e.g. by using
vb2_video_unregister_device()). 

Because the input poller is stopped synchronously by input_unregister_device()
just above, no further frames will arrive. 

Does this cause any thread blocked in VIDIOC_DQBUF or poll() to hang forever
until interrupted by a signal?


[Severity: High]
This is also a pre-existing issue, but does this disconnect sequence create an
unkillable deadlock later on?

If userspace closes the device after a disconnect, the V4L2 core invokes
sur40_stop_streaming(), which calls:

    vb2_wait_for_all_buffers(vq);
    sur40->sequence = -1;

Since input_unregister_device() was already called synchronously in
sur40_disconnect(), the input polling thread is permanently stopped. 

Does this cause vb2_wait_for_all_buffers() to block indefinitely in a
D-state, since the driver-owned buffers will never be processed and returned
via vb2_buffer_done()?

> -	v4l2_device_unregister(&sur40->v4l2);
> -
> -	kfree(sur40->bulk_in_buffer);
> -	kfree(sur40);
>  
>  	usb_set_intfdata(interface, NULL);
>  	dev_dbg(&interface->dev, "%s is now disconnected\n", DRIVER_DESC);
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260826034239.QMESl9TtJLm8R_oB5SkE5YErhpU_WDuou8ER3A1oZmI@z?part=1