From: sashiko-bot@kernel.org
To: "Dmitry Torokhov" <dmitry.torokhov@gmail.com>
Cc: dmitry.torokhov@gmail.com, linux-input@vger.kernel.org
Subject: Re: [PATCH 03/10] Input: synaptics-rmi4 - bound the F54 report size to the allocated buffer
Date: Fri, 26 Jun 2026 05:31:26 +0000 [thread overview]
Message-ID: <20260626053127.573C01F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260626051802.4033172-3-dmitry.torokhov@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] Devm-managed V4L2 video_device leads to Use-After-Free on deferred file close.
- [Medium] Missing vb2_queue_release() leaks videobuf2 resources during device unbind.
--
commit 7c7a1b6617a82d10a8cfe2c055e62e4a1c8fe287
Author: Bryam Vargas <hexlabsecurity@proton.me>
Input: synaptics-rmi4 - bound the F54 report size to the allocated buffer
This commit prevents a buffer overflow in rmi_f54_work() by rejecting reports
that are larger than the allocated size of f54->report_data. It records the
allocation size during probe and ensures the report_size does not exceed it.
> diff --git a/drivers/input/rmi4/rmi_f54.c b/drivers/input/rmi4/rmi_f54.c
> index 8eac320c43e35..75839a54656b9 100644
> --- a/drivers/input/rmi4/rmi_f54.c
> +++ b/drivers/input/rmi4/rmi_f54.c
> @@ -104,6 +104,7 @@ struct f54_data {
>
> enum rmi_f54_report_type report_type;
> u8 *report_data;
> + size_t max_report_size;
> int report_size;
>
> bool is_busy;
[Severity: High]
This isn't a bug introduced by this patch, but looking at struct f54_data
which embeds struct video_device vdev, can its devm-managed lifecycle lead
to a use-after-free on a deferred file close?
If a user holds the video node open while the device is unbound,
rmi_f54_remove() calls video_unregister_device(&f54->vdev).
Devres will then free struct f54_data immediately upon return.
When the user later closes the file descriptor, will the V4L2 core access
the freed video_device to decrement its kref and invoke the release callback?
[Severity: Medium]
This is a pre-existing issue, but does rmi_f54_remove() leak videobuf2
resources during device unbind?
The teardown path unregisters the video device with
video_unregister_device(&f54->vdev).
If userspace requests buffers (e.g., via VIDIOC_REQBUFS) and the device is
subsequently unbound without the application cleanly releasing the buffers,
will the driver leak the videobuf2 kernel resources and allocated buffers
since it fails to call vb2_queue_release()?
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260626051802.4033172-1-dmitry.torokhov@gmail.com?part=3
next prev parent reply other threads:[~2026-06-26 5:31 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-26 5:17 [PATCH 01/10] Input: synaptics-rmi4 - fix F55 transmitter electrode count typo Dmitry Torokhov
2026-06-26 5:17 ` [PATCH 02/10] Input: synaptics-rmi4 - zero report size on F54 work error Dmitry Torokhov
2026-06-26 5:32 ` sashiko-bot
2026-06-26 5:17 ` [PATCH 03/10] Input: synaptics-rmi4 - bound the F54 report size to the allocated buffer Dmitry Torokhov
2026-06-26 5:31 ` sashiko-bot [this message]
2026-06-26 5:17 ` [PATCH 04/10] Input: synaptics-rmi4 - cancel delayed work on F54 remove Dmitry Torokhov
2026-06-26 5:28 ` sashiko-bot
2026-06-26 5:17 ` [PATCH 05/10] Input: synaptics-rmi4 - block s_input when F54 queue is busy Dmitry Torokhov
2026-06-26 5:27 ` sashiko-bot
2026-06-26 5:17 ` [PATCH 06/10] Input: synaptics-rmi4 - propagate F54 worker errors to V4L2 queue Dmitry Torokhov
2026-06-26 7:30 ` sashiko-bot
2026-06-26 5:17 ` [PATCH 07/10] Input: synaptics-rmi4 - check V4L2 buffer size in F54 queue Dmitry Torokhov
2026-06-26 5:31 ` sashiko-bot
2026-06-26 5:17 ` [PATCH 08/10] Input: synaptics-rmi4 - F54 style and typo fixes Dmitry Torokhov
2026-06-26 5:29 ` sashiko-bot
2026-06-26 5:17 ` [PATCH 09/10] Input: synaptics-rmi4 - change report_size to size_t in F54 Dmitry Torokhov
2026-06-26 5:29 ` sashiko-bot
2026-06-26 5:17 ` [PATCH 10/10] Input: synaptics-rmi4 - use __le16 for FIFO offset " Dmitry Torokhov
2026-06-26 5:33 ` sashiko-bot
2026-06-26 5:31 ` [PATCH 01/10] Input: synaptics-rmi4 - fix F55 transmitter electrode count typo sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260626053127.573C01F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dmitry.torokhov@gmail.com \
--cc=linux-input@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.