From: sashiko-bot@kernel.org
To: "Yousef Alhouseen" <alhouseenyousef@gmail.com>
Cc: dmitry.torokhov@gmail.com, linux-input@vger.kernel.org
Subject: Re: [PATCH 4/4] HID: roccat-savu: reject short special reports
Date: Sun, 28 Jun 2026 16:49:39 +0000 [thread overview]
Message-ID: <20260628164940.2F5F21F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260628163527.14279-4-alhouseenyousef@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] The driver acquires a mutex in the raw_event handler path, which executes in atomic (softIRQ) context, leading to a scheduling-while-atomic bug or deadlock.
- [Medium] The roccat driver leaks the memory allocated for circular buffer reports when the device is destroyed.
--
commit 60d1ec57aac96f7ad83f249887da4a3aa3a3f7c4
Author: Yousef Alhouseen <alhouseenyousef@gmail.com>
HID: roccat-savu: reject short special reports
savu_report_to_chrdev() casts special reports to a five-byte structure and
reads all of its payload fields without checking the received size. A
malformed USB device can therefore trigger out-of-bounds reads from the
input buffer when the character device is claimed. Pass the report size
into the helper and require the complete structure.
> diff --git a/drivers/hid/hid-roccat-savu.c b/drivers/hid/hid-roccat-savu.c
> index 6791369335601..04fa4c50cfa4b 100644
> --- a/drivers/hid/hid-roccat-savu.c
> +++ b/drivers/hid/hid-roccat-savu.c
[ ... ]
> @@ -183,7 +184,7 @@ static int savu_raw_event(struct hid_device *hdev,
> return 0;
>
> if (savu->roccat_claimed)
> - savu_report_to_chrdev(savu, data);
> + savu_report_to_chrdev(savu, data, size);
[Severity: High]
This is a pre-existing issue, but can this lead to a scheduling-while-atomic
bug?
The savu_raw_event() callback runs in atomic context (softIRQ). When it
calls savu_report_to_chrdev(), the execution path proceeds to
roccat_report_event() in drivers/hid/hid-roccat.c, which acquires
sleeping locks:
drivers/hid/hid-roccat.c:roccat_report_event() {
...
mutex_lock(&device->readers_lock);
mutex_lock(&device->cbuf_lock);
...
}
[Severity: Medium]
This is also a pre-existing issue, but does this code leak the memory
allocated for circular buffer reports when the device is destroyed?
In drivers/hid/hid-roccat.c:roccat_report_event(), kmemdup() dynamically
allocates memory for the report:
new_value = kmemdup(data, device->report_size, GFP_ATOMIC);
However, when the device is freed in roccat_release() or
roccat_disconnect() using kfree(device), the dynamically allocated report
values in the circular buffer do not appear to be cleaned up.
>
> return 0;
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260628163527.14279-1-alhouseenyousef@gmail.com?part=4
prev parent reply other threads:[~2026-06-28 16:49 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-28 16:35 [PATCH 1/4] HID: elo: ignore short touch reports Yousef Alhouseen
2026-06-28 16:35 ` [PATCH 2/4] HID: cougar: reject short vendor reports Yousef Alhouseen
2026-06-28 16:49 ` sashiko-bot
2026-06-28 16:35 ` [PATCH 3/4] HID: zydacron: reject short key reports Yousef Alhouseen
2026-06-28 16:35 ` [PATCH 4/4] HID: roccat-savu: reject short special reports Yousef Alhouseen
2026-06-28 16:49 ` sashiko-bot [this message]
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=20260628164940.2F5F21F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=alhouseenyousef@gmail.com \
--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.