Re: [PATCH 05/10] Input: synaptics-rmi4 - block s_input when F54 queue is busy

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Using `devm_kzalloc` for a structure containing a V4L2 `video_device` with `video_device_release_empty` leads to a Use-After-Free on unbind.
--

commit 49068cdcddfc12eacb30d46e9f92bd95fd14648f
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Input: synaptics-rmi4 - block s_input when F54 queue is busy

Changing the input (diagnostic report type) mid-stream changes the report size.
Since V4L2 buffers are allocated based on the size at stream start, changing
the input while streaming could lead to a heap buffer overflow if the new size
is larger than the allocated buffers.

> diff --git a/drivers/input/rmi4/rmi_f54.c b/drivers/input/rmi4/rmi_f54.c
> index aebe74d2032cd..e86dfc9ce7d9a 100644
> --- a/drivers/input/rmi4/rmi_f54.c
> +++ b/drivers/input/rmi4/rmi_f54.c
> @@ -445,7 +445,12 @@ static int rmi_f54_set_input(struct f54_data *f54, unsigned int i)
>  
>  static int rmi_f54_vidioc_s_input(struct file *file, void *priv, unsigned int i)
>  {
> -	return rmi_f54_set_input(video_drvdata(file), i);
> +	struct f54_data *f54 = video_drvdata(file);

[Severity: High]
This isn't a bug introduced by this patch, but could this f54 pointer
reference freed memory during a device unbind?

In rmi_f54_probe(), the f54_data structure is allocated with devm_kzalloc():

    f54 = devm_kzalloc(&fn->dev, sizeof(struct f54_data), GFP_KERNEL);

This ties its lifetime to the physical device rather than the V4L2 character
device reference count. The release callback for the video device is also set
to a dummy function in rmi_f54_video_device:

    .release = video_device_release_empty,

During unbind, rmi_f54_remove() calls video_unregister_device(&f54->vdev) but
returns immediately. This unregisters the V4L2 device without synchronously
waiting for userspace to close open file descriptors, leaving ongoing V4L2
file descriptors pointing at memory that is about to be freed by devres.

If a userspace application keeps the V4L2 device node open, would subsequent
operations or closes (such as vb2_fop_release) attempt to access the vdev and
queue embedded within this already-freed f54_data memory?

> +
> +	if (vb2_is_busy(&f54->queue))
> +		return -EBUSY;
> +
> +	return rmi_f54_set_input(f54, i);
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260626051802.4033172-1-dmitry.torokhov@gmail.com?part=5