From: sashiko-bot@kernel.org
To: "Vicki Pfau" <vi@endrift.com>
Cc: linux-input@vger.kernel.org, dmitry.torokhov@gmail.com
Subject: Re: [PATCH v9 3/3] HID: nintendo: Add unified report format support
Date: Wed, 01 Jul 2026 07:12:30 +0000 [thread overview]
Message-ID: <20260701071230.6B7641F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260701065606.4169999-4-vi@endrift.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [Critical] LED class devices registered with devm_led_classdev_register() outlive their containing switch2_controller structure, leading to a UAF if accessed via sysfs after the device is unplugged.
--
commit 84beb320490de870df51e881a9a77c861e3838ca
Author: Vicki Pfau <vi@endrift.com>
HID: nintendo: Add unified report format support
This adds support for the "unified" report format that all controllers also
support, which has overlapping fields for like buttons and axes between
them.
> diff --git a/drivers/hid/hid-nintendo.c b/drivers/hid/hid-nintendo.c
> index 96463e1586bbd..b406e6cfd221f 100644
> --- a/drivers/hid/hid-nintendo.c
> +++ b/drivers/hid/hid-nintendo.c
[ ... ]
[Severity: Critical]
This is a pre-existing issue, but can this lead to a use-after-free when the
device is unplugged?
Looking at switch2_init_input(), LEDs are registered with a devm action tied to
input->dev:
drivers/hid/hid-nintendo.c:switch2_init_input() {
...
ret = devm_led_classdev_register(&input->dev, led);
...
}
This means their teardown action is delayed until the input device's kobject is
released.
However, the ns2 structure containing the leds array is freed manually in
switch2_kref_put() upon device removal:
drivers/hid/hid-nintendo.c:switch2_kref_put() {
...
kfree(ns2);
...
}
Because the LED sysfs device is a child of input->dev, it prevents input->dev
from being released until it is unregistered. This creates a circular dependency
where the devm cleanup is never triggered.
If a process keeps the LED sysfs file open, input->dev remains alive, but ns2
is freed. Does this leave the LED sysfs endpoints pointing to freed memory,
potentially executing function pointers from the freed ns2 structure when
writing to the LED sysfs brightness file?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260701065606.4169999-1-vi@endrift.com?part=3
prev parent reply other threads:[~2026-07-01 7:12 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-01 6:56 [PATCH v9 0/3] HID: nintendo: Add preliminary Switch 2 controller driver Vicki Pfau
2026-07-01 6:56 ` [PATCH v9 1/3] " Vicki Pfau
2026-07-01 7:12 ` sashiko-bot
2026-07-01 6:56 ` [PATCH v9 2/3] HID: nintendo: Add rumble support for Switch 2 controllers Vicki Pfau
2026-07-01 7:17 ` sashiko-bot
2026-07-01 6:56 ` [PATCH v9 3/3] HID: nintendo: Add unified report format support Vicki Pfau
2026-07-01 7:12 ` 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=20260701071230.6B7641F000E9@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 \
--cc=vi@endrift.com \
/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