hid_go_cfg_probe() initialises drvdata.go_cfg_setup and schedules it
to run 2 ms later:

    INIT_DELAYED_WORK(&drvdata.go_cfg_setup, &cfg_setup);
    schedule_delayed_work(&drvdata.go_cfg_setup, msecs_to_jiffies(2));

cfg_setup() dereferences drvdata.hdev to issue MCU command requests.
hid_go_cfg_remove() tears down sysfs and stops the HID device, ending
with hid_set_drvdata(hdev, NULL), but never drains the delayed work.
If the device is unbound within the 2 ms scheduling delay (a probe
failure rolling back via remove, or a fast rmmod after probe), the
work fires after hid_set_drvdata(NULL) has cleared the back pointer,
leaving cfg_setup() with a NULL or stale drvdata.hdev.

Mirror the sibling driver hid-lenovo-go-s.c, whose hid_gos_cfg_remove()
already calls cancel_delayed_work_sync() on its analogous work, and
drain go_cfg_setup at the top of hid_go_cfg_remove().  The cancel
must come before guard(mutex)(&drvdata.cfg_mutex) because cfg_setup()
acquires that mutex; reversing the order would deadlock.

Fixes: d69ccfcbc955 ("HID: hid-lenovo-go: Add Lenovo Legion Go Series HID Driver")
Cc: stable@vger.kernel.org
Signed-off-by: Manish Khadka <maskmemanish@gmail.com>
---
 drivers/hid/hid-lenovo-go.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/hid/hid-lenovo-go.c b/drivers/hid/hid-lenovo-go.c
index d4d26c783356..ef69869f0a00 100644
--- a/drivers/hid/hid-lenovo-go.c
+++ b/drivers/hid/hid-lenovo-go.c
@@ -2408,6 +2408,13 @@ static int hid_go_cfg_probe(struct hid_device *hdev,
 
 static void hid_go_cfg_remove(struct hid_device *hdev)
 {
+	/*
+	 * cfg_setup is scheduled from hid_go_cfg_probe() with a 2 ms delay;
+	 * drain it here before tearing down so the workqueue cannot run
+	 * after hid_set_drvdata(NULL) and dereference a stale drvdata.hdev.
+	 */
+	cancel_delayed_work_sync(&drvdata.go_cfg_setup);
+
 	guard(mutex)(&drvdata.cfg_mutex);
 	sysfs_remove_groups(&hdev->dev.kobj, top_level_attr_groups);
 	hid_hw_close(hdev);
-- 
2.43.0

On May 15, 2026 8:36:07 AM PDT, Manish Khadka <maskmemanish@gmail.com> wrote:
>hid_go_cfg_probe() initialises drvdata.go_cfg_setup and schedules it
>to run 2 ms later:
>
>    INIT_DELAYED_WORK(&drvdata.go_cfg_setup, &cfg_setup);
>    schedule_delayed_work(&drvdata.go_cfg_setup, msecs_to_jiffies(2));
>
>cfg_setup() dereferences drvdata.hdev to issue MCU command requests.
>hid_go_cfg_remove() tears down sysfs and stops the HID device, ending
>with hid_set_drvdata(hdev, NULL), but never drains the delayed work.
>If the device is unbound within the 2 ms scheduling delay (a probe
>failure rolling back via remove, or a fast rmmod after probe), the
>work fires after hid_set_drvdata(NULL) has cleared the back pointer,
>leaving cfg_setup() with a NULL or stale drvdata.hdev.
>
>Mirror the sibling driver hid-lenovo-go-s.c, whose hid_gos_cfg_remove()
>already calls cancel_delayed_work_sync() on its analogous work, and
>drain go_cfg_setup at the top of hid_go_cfg_remove().  The cancel
>must come before guard(mutex)(&drvdata.cfg_mutex) because cfg_setup()
>acquires that mutex; reversing the order would deadlock.
>
>Fixes: d69ccfcbc955 ("HID: hid-lenovo-go: Add Lenovo Legion Go Series HID Driver")
>Cc: stable@vger.kernel.org
>Signed-off-by: Manish Khadka <maskmemanish@gmail.com>
>---
> drivers/hid/hid-lenovo-go.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
>diff --git a/drivers/hid/hid-lenovo-go.c b/drivers/hid/hid-lenovo-go.c
>index d4d26c783356..ef69869f0a00 100644
>--- a/drivers/hid/hid-lenovo-go.c
>+++ b/drivers/hid/hid-lenovo-go.c
>@@ -2408,6 +2408,13 @@ static int hid_go_cfg_probe(struct hid_device *hdev,
> 
> static void hid_go_cfg_remove(struct hid_device *hdev)
> {
>+	/*
>+	 * cfg_setup is scheduled from hid_go_cfg_probe() with a 2 ms delay;
>+	 * drain it here before tearing down so the workqueue cannot run
>+	 * after hid_set_drvdata(NULL) and dereference a stale drvdata.hdev.
>+	 */
>+	cancel_delayed_work_sync(&drvdata.go_cfg_setup);
>+
> 	guard(mutex)(&drvdata.cfg_mutex);
> 	sysfs_remove_groups(&hdev->dev.kobj, top_level_attr_groups);
> 	hid_hw_close(hdev);


Looks good. 

Reviewed-by: Derek J. Clark <derekjohn.clark@gmail.com>