From: sashiko-bot@kernel.org
To: "Hyeonsu Choi" <chlgustn3171@gmail.com>
Cc: linux-input@vger.kernel.org, dmitry.torokhov@gmail.com
Subject: Re: [PATCH] HID: input: allocate input_dev name/phys/uniq using hid device devres
Date: Tue, 14 Jul 2026 12:18:18 +0000 [thread overview]
Message-ID: <20260714121819.5FCC91F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260714120052.255085-1-chlgustn3171@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Use-After-Free of input_dev string fields (name, phys, uniq) on device unbind.
- [Low] Memory leak of devm_kstrdup strings in the error path.
--
--- Patch [1]: [PATCH] HID: input: allocate input_dev name/phys/uniq using hid device devres ---
commit ae1934cecc0a7213604df29b6d6486b4090d9b54
Author: Hyeonsu Choi <chlgustn3171@gmail.com>
HID: input: allocate input_dev name/phys/uniq using hid device devres
This commit modifies hidinput_allocate() to dynamically allocate the
input_dev name, phys, and uniq strings using devm_kstrdup() tied to
the parent HID device. It also introduces an error handling path to
clean up if the allocations fail.
> diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
> --- a/drivers/hid/hid-input.c
> +++ b/drivers/hid/hid-input.c
> @@ -2126,9 +2126,20 @@ static struct hid_input *hidinput_allocate(struct hid_device *hid,
[ ... ]
> - input_dev->name = hidinput->name ? hidinput->name : hid->name;
> - input_dev->phys = hid->phys;
> - input_dev->uniq = hid->uniq;
> + const char *name = hidinput->name ? hidinput->name : hid->name;
> +
> + input_dev->name = devm_kstrdup(&hid->dev, name, GFP_KERNEL);
> + if (!input_dev->name)
> + goto fail;
> +
> + input_dev->phys = devm_kstrdup(&hid->dev, hid->phys, GFP_KERNEL);
[Severity: High]
If a userspace process holds an open file descriptor for the evdev node
(/dev/input/eventX), the input_dev will outlive the parent hid->dev.
When the HID device is unbound, devres will free these strings.
Can this cause a use-after-free when userspace later queries the
name, phys, or uniq strings via ioctl (e.g., EVIOCGNAME)?
> + if (!input_dev->phys)
> + goto fail;
> +
> + input_dev->uniq = devm_kstrdup(&hid->dev, hid->uniq, GFP_KERNEL);
> + if (!input_dev->uniq)
> + goto fail;
> +
[ ... ]
> @@ -2144,6 +2155,8 @@ static struct hid_input *hidinput_allocate(struct hid_device *hid,
> return hidinput;
>
> fail:
> + if (hidinput)
> + kfree(hidinput->name);
> kfree(hidinput);
> input_free_device(input_dev);
> hid_err(hid, "Out of memory during hid input probe\n");
[Severity: Low]
If devm_kstrdup() fails for phys or uniq, the code jumps here to the
error path. The earlier successful devm_kstrdup() allocations remain
tied to &hid->dev.
If the caller continues the device probe successfully after this failure,
will these strings be leaked for the lifetime of the HID device?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260714120052.255085-1-chlgustn3171@gmail.com?part=1
next prev parent reply other threads:[~2026-07-14 12:18 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-14 12:00 [PATCH] HID: input: allocate input_dev name/phys/uniq using hid device devres Hyeonsu Choi
2026-07-14 12:18 ` sashiko-bot [this message]
2026-07-14 13:33 ` chlgustn3171
2026-07-14 13:39 ` chlgustn3171
2026-07-15 5:57 ` Dmitry Torokhov
2026-07-15 6:37 ` chlgustn3171
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=20260714121819.5FCC91F00A3A@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=chlgustn3171@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.