Re: [PATCH] Input: ati_remote2 - fix type confusion in device attribute handlers

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

On Fri, Oct 09, 2026 at 08:10:08AM +0200, Krzysztof Kozlowski wrote:
> 
> On Fri, 09 Oct 2026 12:03:02 +0800, Haotian Zhang wrote:
> > The channel_mask and mode_mask attributes are instantiated by the driver
> > core through struct usb_driver::dev_groups, so they are attached to the
> > usb_interface bound to the driver, not to the usb_device.  The four
> > show/store handlers still call to_usb_device(dev), which applies the
> > struct usb_device container_of() to a struct usb_interface::dev and thus
> > produces a bogus usb_device pointer.  usb_ifnum_to_if() reads that
> > pointer as udev->actconfig and dereferences it, and its result is passed
> > to usb_get_intfdata() without any NULL check, so reading or writing the
> > world-readable attributes can crash the kernel.
> > 
> > Use to_usb_interface(dev) so the handlers recover the interface that the
> > attributes belong to, matching the other drivers converted to dev_groups.
> > 
> > Fixes: b20d6bf8014b ("Input: ati-remote2 - use driver core to instantiate device attributes")
> > Assisted-by: DeepSeek-V4.1-Flash
> > Signed-off-by: Haotian Zhang <vulab@iscas.ac.cn>
> > ---
> >  drivers/input/misc/ati_remote2.c | 12 ++++--------
> >  1 file changed, 4 insertions(+), 8 deletions(-)
> > 
> 
> 
> 
> Multiple things here:
> 1. Your team ignored completely previous feedback.
> 
> 2. You use multiple identities with this email, thus I actually doubt we speak
>    with actual person.
> 
> 3. Finally, same feedback:
> You sent multiple independent patches, to multiple independent
> subsystems. The amount of these patches clearly suggest this was
> AI generated and most likely not tested.
> 
> More importantly, you sent all this work without properly organizing
> relevant patches into patchsets. This makes reviewing difficult
> and might cause multiple reviewers to address the same issue.
> Replying to the entire set is impossible and requires handling each
> patch independently, instead of applying or discarding the set.
> Maintainers also won't see the bigger picture of your work. Quite
> worrying.
> 
> This is on the verge of hostile patch: bomb us with so many
> contributions, we won't be able to handle them in efficient manner,
> like responding ONCE to ask you to slow down.  Considering all this
> is untested and LLM generated, I have even more doubts whether this
> should be considered for review.

Not sure what was wrong with previous submissions, this is first time I
see it. This fixes a valid regression that I introduced when moved
attribute registration into dev_groups and inadvertently attached it to
the wrong device instance. We could consider reverting the original
patch, but since nobody complained in 2 years I think I'll simply take
this one.

Thanks.

-- 
Dmitry