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

[chlgustn3171]

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
<dmitry.torokhov@xxxxxxxxx> wrote:
>
> Hi,
>
> On Tue, Jul 14, 2026 at 10:39:09PM +0900, chlgustn3171 wrote:
> > Adding maintainers and mailing list to CC. Sorry for the omission.
> >
> > On Tue, Jul 14, 2026 at 10:33 PM chlgustn3171 <chlgustn3171@xxxxxxxxx> wrote:
> > >
> > > On Tue, Jul 14, 2026 at 9:18 PM sashiko-bot wrote:
> > > > [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