Re: [PATCH 07/10] Input: synaptics-rmi4 - check V4L2 buffer size in F54 queue

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

Pre-existing issues:
- [Critical] The driver embeds V4L2 structures (`video_device`, `vb2_queue`, `mutex`) within `struct f54_data` allocated using `devm_kzalloc()`, leading to a use-after-free when the device is unbound while file descriptors remain open.
--

commit 5a88e74ace3829801abe168bf6f2a7e65b6ad4b8
Author: Dmitry Torokhov [off-list ref]

Input: synaptics-rmi4 - check V4L2 buffer size in F54 queue

Add a safety check in rmi_f54_buffer_queue() to ensure that the requested
report size (f54->report_size) does not exceed the actual allocated size of
the V4L2 buffer (vb2_plane_size()). This provides a defense-in-depth
measure against any potential size mismatches between the V4L2 queue and
the driver's internal state.

[Severity: Critical]
This is a pre-existing issue, but does the driver have a use-after-free
in the V4L2 device unbind path?

In drivers/input/rmi4/rmi_f54.c:rmi_f54_probe(), f54_data is allocated
using devm:

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

And in rmi_f54_remove():

    video_unregister_device(&f54->vdev);

When the device is unbound while a user holds the V4L2 file descriptor
open, devres will immediately free f54_data after rmi_f54_remove()
returns. However, the V4L2 core retains a reference to the embedded
video_device for the open file descriptor.

Additionally, vb2_queue_release() is never called, leaving active V4L2
waitqueues pointing to the freed memory.

Can subsequent operations on the open file descriptor dereference the
freed f54->vdev, f54->lock, or f54->queue?

[ ... ]

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