Re: [PATCH v2 0/2] wifi: carl9170: revert broken devres conversions for input and hwrng

[Christian Lamparter]

On 10/10/26 1:13 AM, Dmitry Torokhov wrote:
> Hi Christian,
>
> On Fri, Oct 09, 2026 at 09:37:36PM +0200, Christian Lamparter wrote:
> > On 10/8/26 11:39 AM, Dmitry Torokhov wrote:
> > > Commits 23de0fa0d2a0 ("carl9170: devres-ing hwrng_register usage") and
> > > 87ddb2fc29f1 ("carl9170: devres-ing input_allocate_device") converted
> > > the HWRNG and WPS button input device registrations in carl9170 to
> > > devres attached to the parent struct usb_device (&ar->udev->dev) and
> > > removed explicit unregistration from carl9170_unregister().
> > >
> > > In carl9170_usb_disconnect(), the driver calls carl9170_unregister()
> > > followed immediately by carl9170_free(), which frees struct ar9170
> > > inside the interface .disconnect() callback before devres_release_all()
> > > runs. Furthermore, devres on &ar->udev->dev is not released on
> > > interface unbind or registration failure in carl9170_register().
> > > As a result, both the WPS input device (whose input->name and
> > > input->phys point into freed memory) and the embedded struct hwrng
> > > remain registered after struct ar9170 has been freed, leading to
> > > use-after-free bugs.
> >
> > Ok, so you just reworded your patch? Sight...
>
> Yes, as I promised I would.
>
> > looking at the WPS input
> >
> > |        input->name = ar->wps.name;
> > |        input->phys = ar->wps.phys;
> > |        input->id.bustype = BUS_USB;
> > |        input->dev.parent = &ar->hw->wiphy->dev;
> >            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >
> > the input's dev.parent is set to ar->hw->wiphy->dev and not ar->udev->dev, right?
> > Does this do anything at all? If not, why? The wiphy gets shutdown by
> > ieee80211_unregister() and having the "freeing" stick around after the USB device
> > is gone should not hurt, right?
>
> devm_input_allocate_device() explicitly states:
>
> 	NOTE: the owner device is set up as parent of input device and
> 	users should not override it.

Yeah, and this is something you added in 2012... The carl9170 code driver
is back from 2010.

So, was this changed to "break it", rather than the driver?

From my POV: What's the point of devres then? And why are you so "eager"
to revert the changes.

Cheers,
Christian