[bug report] Potential order bug in 'drivers/input/misc', particularly 'ati_remote2.c', 'cm109.c', 'keyspan_remote.c'

[bug report] Potential order bug in 'drivers/input/misc', particularly 'ati_remote2.c', 'cm109.c', 'keyspan_remote.c'

[Ginger]

Dear Linux kernel maintainers,

My research-based static analyzer found a potential order bug within
the ' drivers/input/misc' subsystem. I will use the potential bug
found in 'drivers/input/misc/ati_remote2.c' as the typical example.
The similar potential bug patterns are also observed in 'cm109.c' and
'keyspan_remote.c'.

Kernel version: long-term kernel v6.18.9

Potential issue:
T0:
ati_remote2_disconnect
    --> ar2 = usb_get_intfdata(interface);
    --> usb_set_intfdata(interface, NULL);
    --> input_unregister_device(ar2->idev);
    --> usb_driver_release_interface(&ati_remote2_driver, ar2->intf[1]);
    --> kfree(ar2)

T1:
ati_remote2_store_channel_mask (registered as the device attribute
function and exposed via the sysfs)
    --> struct ati_remote2 *ar2 = usb_get_intfdata(intf);
    --> ar2->mode_mask = mask;

In T0, the interface is nullified before its get deregistered. Thus,
it is possible for T1 to still get the usb dev and access it via the
interface, which, however, has been already nullified or even freed.
This similar pattern is also observed in 'cm109_usb_disconnect()' of
file 'cm109.c' and 'keyspan_disconnect()' of file 'keyspan_remote.c'.

Thank you for your time and consideration.

Sincerely,
Ginger

Re: [bug report] Potential order bug in 'drivers/input/misc', particularly 'ati_remote2.c', 'cm109.c', 'keyspan_remote.c'

[Dmitry Torokhov]

Hi Ginger,

On Tue, Apr 28, 2026 at 12:18:46PM +0800, Ginger wrote:
> Dear Linux kernel maintainers,
> 
> My research-based static analyzer found a potential order bug within
> the ' drivers/input/misc' subsystem. I will use the potential bug
> found in 'drivers/input/misc/ati_remote2.c' as the typical example.
> The similar potential bug patterns are also observed in 'cm109.c' and
> 'keyspan_remote.c'.
> 
> Kernel version: long-term kernel v6.18.9
> 
> Potential issue:
> T0:
> ati_remote2_disconnect
>     --> ar2 = usb_get_intfdata(interface);
>     --> usb_set_intfdata(interface, NULL);
>     --> input_unregister_device(ar2->idev);
>     --> usb_driver_release_interface(&ati_remote2_driver, ar2->intf[1]);
>     --> kfree(ar2)
> 
> T1:
> ati_remote2_store_channel_mask (registered as the device attribute
> function and exposed via the sysfs)
>     --> struct ati_remote2 *ar2 = usb_get_intfdata(intf);
>     --> ar2->mode_mask = mask;
> 
> In T0, the interface is nullified before its get deregistered. Thus,
> it is possible for T1 to still get the usb dev and access it via the
> interface, which, however, has been already nullified or even freed.
> This similar pattern is also observed in 'cm109_usb_disconnect()' of
> file 'cm109.c' and 'keyspan_disconnect()' of file 'keyspan_remote.c'.

Driver core is supposed to remove sysfs attributes before calling
remove() or disconnect() (see drivers/base/dd.c::device_remove()) and
sysfs ensures that all threads leave sysfs show() and store() methods
before the call to delete the attributes returns.

Thanks.

-- 
Dmitry