From: sashiko-bot@kernel.org
To: "Dmitry Antipov" <dmantipov@yandex.ru>
Cc: linux-input@vger.kernel.org, dmitry.torokhov@gmail.com
Subject: Re: [PATCH 2/2] HID: roccat: use kref to manage device instances
Date: Wed, 02 Sep 2026 10:04:13 +0000 [thread overview]
Message-ID: <20260902100414.54F4F1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260902094551.200587-2-dmantipov@yandex.ru>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
New issues:
- [Critical] Removal of the unconditional `devices[minor] = NULL` in `roccat_disconnect()` leaves a dangling pointer in the global array, allowing racing `open()` calls to access a freed `hid_device`.
- [High] Mismatched kref accounting permanently leaks `struct roccat_device` references on every open cycle.
Pre-existing issues:
- [Critical] Pre-existing logic flaw: `roccat_release()` incorrectly looks up the device via the global `devices` array instead of using `file->private_data`.
--
commit 215425e9faf722882019fabfa914bec7f0229c93
Author: Dmitry Antipov <dmantipov@yandex.ru>
HID: roccat: use kref to manage device instances
This patch introduces a kref to manage the lifecycle of roccat_device
instances. It replaces custom lifecycle tracking in an attempt to resolve
Use-After-Free conditions between open/release and connect/disconnect.
Link: https://syzkaller.appspot.com/bug?extid=d632e93ffcd1452bc61e
> diff --git a/drivers/hid/hid-roccat.c b/drivers/hid/hid-roccat.c
> index 5deb6da8d4f74..264977e8e3010 100644
> --- a/drivers/hid/hid-roccat.c
> +++ b/drivers/hid/hid-roccat.c
[ ... ]
> @@ -193,6 +196,7 @@ static int roccat_open(struct inode *inode, struct file *file)
> }
> }
>
> + kref_get(&device->ref);
[Severity: High]
Does this unconditionally acquire a reference for every open file descriptor
without a corresponding unconditional release?
In roccat_connect(), the kref is initialized to 1. Here in roccat_open(), a
reference is added for every reader.
However, roccat_release() only drops a reference if it is the last reader and
the device is already disconnected. Any open/close cycle while the device is
still connected will leak a reference.
[ ... ]
> @@ -235,7 +239,8 @@ static int roccat_release(struct inode *inode, struct file *file)
> hid_hw_power(device->hid, PM_HINT_NORMAL);
> hid_hw_close(device->hid);
> } else {
> - roccat_free_device(device);
> + if (kref_put(&device->ref, roccat_free_device))
> + devices[minor] = NULL;
> }
> }
[Severity: Critical]
This is a pre-existing issue, but does roccat_release() look up the device
incorrectly?
roccat_release() retrieves the device from the global array:
device = devices[minor];
If the original device was disconnected and a new device connected in the same
minor slot, this lookup grabs the new device instead of the one associated
with the closing file descriptor via reader->device. This can corrupt the
readers list and incorrectly alter the open count of the new device.
[Severity: High]
Additionally, since kref_put() is only called in the else branch (when it is
the last reader and the device no longer exists), won't this leak references
for all standard open/close operations when the device is still connected?
[ ... ]
> @@ -367,21 +373,22 @@ void roccat_disconnect(int minor)
> struct roccat_device *device;
>
> mutex_lock(&devices_lock);
> +
> device = devices[minor];
> + if (!device)
> + goto out;
>
> device->exist = 0; /* TODO exist maybe not needed */
> -
> device_destroy(device->dev->class, MKDEV(roccat_major, minor));
>
> - devices[minor] = NULL;
> -
[Severity: Critical]
Can removing this unconditional clearance leave a dangling pointer in the
global devices array?
If the device is disconnected while held open, the open count is > 0, so the
kref_put() below is bypassed. This means devices[minor] is not cleared to
NULL.
After disconnect, the HID subsystem will eventually free the underlying
device->hid. If a user subsequently closes their file descriptor, the
device->open count reaches 0. Due to the kref leaks, the device structure is
still not freed.
If a new roccat_open() call occurs, it will find the stale pointer in
devices[minor]. Because device->open is now 0, it will execute:
error = hid_hw_power(device->hid, PM_HINT_FULLON);
Can this cause a use-after-free on the hid_device pointer?
> if (device->open) {
> hid_hw_close(device->hid);
> wake_up_interruptible(&device->wait);
> } else {
> - roccat_free_device(device);
> + if (kref_put(&device->ref, roccat_free_device))
> + devices[minor] = NULL;
> }
[Severity: High]
Does this also fail to drop the initial connection reference if the device is
disconnected while open?
Because the kref_put() is only in the else branch, a device that is unplugged
while open will never drop its initial reference from roccat_connect(),
causing it to permanently leak.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260902094551.200587-1-dmantipov@yandex.ru?part=2
next prev parent reply other threads:[~2026-09-02 10:04 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-02 9:45 [PATCH 1/2] HID: roccat: fix locking in roccat_connect() and roccat_disconnect() Dmitry Antipov
2026-09-02 9:45 ` [PATCH 2/2] HID: roccat: use kref to manage device instances Dmitry Antipov
2026-09-02 10:04 ` sashiko-bot [this message]
2026-09-02 10:04 ` [PATCH 1/2] HID: roccat: fix locking in roccat_connect() and roccat_disconnect() 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=20260902100414.54F4F1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dmantipov@yandex.ru \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox