Re: [PATCH] HID: input: allocate input_dev name/phys/uniq using hid device devres

Hi Dmitry,

Thanks for the detailed explanation on devres lifecycle and device refcounting.

I agree the patch is unnecessary, and that the syzbot trace is likely
a false positive or external memory corruption. I will drop this
patch.

Thanks again for the review.

Regards, Hyeonsu


On Wed, Jul 15, 2026 at 2:57 PM Dmitry Torokhov
[off-list ref] wrote:

Hi,

On Tue, Jul 14, 2026 at 10:39:09PM +0900, chlgustn3171 wrote:

quoted

Adding maintainers and mailing list to CC. Sorry for the omission.

On Tue, Jul 14, 2026 at 10:33 PM chlgustn3171 [off-list ref] wrote:

quoted

On Tue, Jul 14, 2026 at 9:18 PM sashiko-bot wrote:

quoted

[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)?

Thanks for the review.

Using &hid->dev here is intentional.
Using the input device for devm-managed input_dev strings is
problematic; see CVE-2023-53454, where the allocation was moved to the
HID device because the input device unregister path may still use the
name for uevents.

Thank you for the patch. However, I do not believe it fixes anything, as
moving to devres will not extend (and may even shorten) life time of
name, phys and uniq. Normally they are character array members of HID
device, and HID device continues existing past drivers disconnecting
from it. OTOH devres-controlled resources will get freed when driver
unbinds from a device.

Additionally, HID devices are parents of input devices, and should stick
around because input devices hold references to their parents until
device_del() is called in input_unregister_device(). However before that
it will disconnect this input device from all the handlers, including
evdev, evdev will mark the device as !exist and evdev ioctl will not
attempt to process ioctls for such device.

I however am not sure why we see this syzkaller report. Maybe there is
memory corruption somewhere or maybe syzkaller itself gets confused when
tracing numerous allocations.

Thanks.

--
Dmitry