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

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

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@gmail.com> 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