[PATCH v2] HID: hid-oxp: fix UAF on pending work in remove()

[PATCH v2] HID: hid-oxp: fix UAF on pending work in remove()

[Shengzhuo Wei]

oxp_cfg_probe() arms drvdata.oxp_mcu_init to run 50 ms after probe, and
oxp_mcu_init_fn() dereferences drvdata.hdev to issue MCU output reports
(hid_hw_output_report() followed by msleep(200)). The oxp_rgb_queue and
oxp_btn_queue workers are wired up the same way. oxp_hid_remove()
cancels all three with the non-synchronising cancel_delayed_work(), so a
worker already running is not waited for; removing the device while a
worker is asleep then frees the hid_device underneath it, leaving
drvdata.hdev stale -- a use-after-free when the worker wakes.

Use disable_delayed_work_sync() for all three in oxp_hid_remove(): it
drains a running worker and, unlike cancel_delayed_work_sync(), leaves
the works disabled so they cannot be re-armed by oxp_hid_raw_event_gen_2()
or oxp_rgb_brightness_set() while the device is torn down. Arm
oxp_mcu_init only after devm_device_add_group() succeeds in
oxp_cfg_probe(), so a probe failure can no longer leave it pending to
fire on the hid_device the caller tears down.

Fixes: 84910c459d65 ("HID: hid-oxp: Add OneXPlayer configuration driver")
Fixes: e4c850a6e750 ("HID: hid-oxp: Add Button Mapping Interface")
Fixes: 2f424f28fb39 ("HID: hid-oxp: Add Second Generation Gamepad Mode Switch")
Cc: stable@vger.kernel.org
Signed-off-by: Shengzhuo Wei <me@cherr.cc>
---
Same delayed-work use-after-free class as the 7.2-rc6 sweep
(hid-lenovo-go, hid-lenovo-go-s, hid-lg-g15, hid-appleir, hid-letsketch);
hid-oxp was missed.
---
Changes in v2:
- Use disable_delayed_work_sync() instead of cancel_delayed_work_sync()
  so the works cannot be re-armed (e.g. via oxp_rgb_brightness_set())
  while the device is being torn down (Dmitry Torokhov).
- Arm oxp_mcu_init only after devm_device_add_group() succeeds, so a
  probe failure can no longer leave it pending to fire on a freed
  hid device (sashiko).
- Link to v1: https://lore.kernel.org/r/20260804-oxp-fix-v1-1-51a4fe787167@cherr.cc
---
 drivers/hid/hid-oxp.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/hid/hid-oxp.c b/drivers/hid/hid-oxp.c
index 20a54f337220dc2aee3483a14d542b66c487bd60..abd622ff1b26b312ad9c8a4375822832f8371533 100644
--- a/drivers/hid/hid-oxp.c
+++ b/drivers/hid/hid-oxp.c
@@ -1501,14 +1501,14 @@ static int oxp_cfg_probe(struct hid_device *hdev, u16 up)
 	drvdata.gamepad_mode = OXP_GP_MODE_XINPUT;
 	drvdata.rumble_intensity = 5;
 
-	INIT_DELAYED_WORK(&drvdata.oxp_mcu_init, oxp_mcu_init_fn);
-	mod_delayed_work(system_wq, &drvdata.oxp_mcu_init, msecs_to_jiffies(50));
-
 	ret = devm_device_add_group(&hdev->dev, &oxp_cfg_attrs_group);
 	if (ret)
 		return dev_err_probe(&hdev->dev, ret,
 				     "Failed to attach configuration attributes\n");
 
+	INIT_DELAYED_WORK(&drvdata.oxp_mcu_init, oxp_mcu_init_fn);
+	mod_delayed_work(system_wq, &drvdata.oxp_mcu_init, msecs_to_jiffies(50));
+
 	return 0;
 }
 
@@ -1552,9 +1552,9 @@ static int oxp_hid_probe(struct hid_device *hdev,
 
 static void oxp_hid_remove(struct hid_device *hdev)
 {
-	cancel_delayed_work(&drvdata.oxp_rgb_queue);
-	cancel_delayed_work(&drvdata.oxp_btn_queue);
-	cancel_delayed_work(&drvdata.oxp_mcu_init);
+	disable_delayed_work_sync(&drvdata.oxp_rgb_queue);
+	disable_delayed_work_sync(&drvdata.oxp_btn_queue);
+	disable_delayed_work_sync(&drvdata.oxp_mcu_init);
 	hid_hw_close(hdev);
 	hid_hw_stop(hdev);
 }

---
base-commit: 075b74841bd0065a3bda3440873c747938e69b68
change-id: 20260804-oxp-fix-879390c5e47f

Best regards,
-- 
Shengzhuo Wei <me@cherr.cc>

Re: [PATCH v2] HID: hid-oxp: fix UAF on pending work in remove()

[Shengzhuo Wei]

On 2026-08-04 17:50, Shengzhuo Wei wrote:
> ---
>  drivers/hid/hid-oxp.c | 12 ++++++------
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/hid/hid-oxp.c b/drivers/hid/hid-oxp.c
> index 20a54f337220dc2aee3483a14d542b66c487bd60..abd622ff1b26b312ad9c8a4375822832f8371533 100644
> --- a/drivers/hid/hid-oxp.c
> +++ b/drivers/hid/hid-oxp.c
> @@ -1501,14 +1501,14 @@ static int oxp_cfg_probe(struct hid_device *hdev, u16 up)
>  	drvdata.gamepad_mode = OXP_GP_MODE_XINPUT;
>  	drvdata.rumble_intensity = 5;
>  
> -	INIT_DELAYED_WORK(&drvdata.oxp_mcu_init, oxp_mcu_init_fn);
> -	mod_delayed_work(system_wq, &drvdata.oxp_mcu_init, msecs_to_jiffies(50));
> -
>  	ret = devm_device_add_group(&hdev->dev, &oxp_cfg_attrs_group);
>  	if (ret)
>  		return dev_err_probe(&hdev->dev, ret,
>  				     "Failed to attach configuration attributes\n");
>  
> +	INIT_DELAYED_WORK(&drvdata.oxp_mcu_init, oxp_mcu_init_fn);
> +	mod_delayed_work(system_wq, &drvdata.oxp_mcu_init, msecs_to_jiffies(50));
> +
>  	return 0;
>  }
>  
> @@ -1552,9 +1552,9 @@ static int oxp_hid_probe(struct hid_device *hdev,
>  
>  static void oxp_hid_remove(struct hid_device *hdev)
>  {
> -	cancel_delayed_work(&drvdata.oxp_rgb_queue);
> -	cancel_delayed_work(&drvdata.oxp_btn_queue);
> -	cancel_delayed_work(&drvdata.oxp_mcu_init);
> +	disable_delayed_work_sync(&drvdata.oxp_rgb_queue);
> +	disable_delayed_work_sync(&drvdata.oxp_btn_queue);
> +	disable_delayed_work_sync(&drvdata.oxp_mcu_init);
>  	hid_hw_close(hdev);
>  	hid_hw_stop(hdev);
>  }
> 
> ---

Hi Dmitry,

Thanks again for the v1 review. Sashiko's v2 review raised two points I
want to act on:

1. "Uninitialized work struct access during early raw events" -- agreed.
   v2 moved INIT_DELAYED_WORK(&drvdata.oxp_mcu_init) to the end of
   oxp_cfg_probe(), widening the window in which an early status report
   could mod_delayed_work() a not-yet-initialized (zeroed) work. I'll
   fix this in v3 by keeping INIT_DELAYED_WORK() before
   devm_device_add_group() and moving only the mod_delayed_work() after
   it: the work is then initialized before any raw event can arm it,
   while a probe failure still can't leave it armed.

2. "Global workqueues permanently disabled on inert interface removal."
   The driver keeps all state in a single static global drvdata, and
   module_hid_driver() binds it to every interface of the device, so
   oxp_hid_remove() runs when any interface is unbound. With
   disable_delayed_work_sync() and no enable_delayed_work() anywhere,
   unbinding an inert interface disables the works for the still-bound
   gamepad interface. cancel_delayed_work_sync() (v1) re-enabled them,
   so it didn't have this side effect.

   This looks like a symptom of the static-global-drvdata issue rather
   than disable_delayed_work_sync() itself -- with per-device drvdata
   each interface would have its own works. Before I send v3, would you
   prefer to keep disable_delayed_work_sync() (and address the
   multi-interface case via the per-device drvdata refactor you
   mentioned as a separate patch), or go back to
   cancel_delayed_work_sync()? I'll hold v3 until I hear from you.

The remaining sashiko items look pre-existing and outside this fix.

Thanks,
Shengzhuo

Re: [PATCH v2] HID: hid-oxp: fix UAF on pending work in remove()

[Derek John Clark]

On Tue, Aug 4, 2026 at 1:06 PM Shengzhuo Wei <me@cherr.cc> wrote:
>
> On 2026-08-04 17:50, Shengzhuo Wei wrote:
> > ---
> >  drivers/hid/hid-oxp.c | 12 ++++++------
> >  1 file changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/hid/hid-oxp.c b/drivers/hid/hid-oxp.c
> > index 20a54f337220dc2aee3483a14d542b66c487bd60..abd622ff1b26b312ad9c8a4375822832f8371533 100644
> > --- a/drivers/hid/hid-oxp.c
> > +++ b/drivers/hid/hid-oxp.c
> > @@ -1501,14 +1501,14 @@ static int oxp_cfg_probe(struct hid_device *hdev, u16 up)
> >       drvdata.gamepad_mode = OXP_GP_MODE_XINPUT;
> >       drvdata.rumble_intensity = 5;
> >
> > -     INIT_DELAYED_WORK(&drvdata.oxp_mcu_init, oxp_mcu_init_fn);
> > -     mod_delayed_work(system_wq, &drvdata.oxp_mcu_init, msecs_to_jiffies(50));
> > -
> >       ret = devm_device_add_group(&hdev->dev, &oxp_cfg_attrs_group);
> >       if (ret)
> >               return dev_err_probe(&hdev->dev, ret,
> >                                    "Failed to attach configuration attributes\n");
> >
> > +     INIT_DELAYED_WORK(&drvdata.oxp_mcu_init, oxp_mcu_init_fn);
> > +     mod_delayed_work(system_wq, &drvdata.oxp_mcu_init, msecs_to_jiffies(50));
> > +
> >       return 0;
> >  }
> >
> > @@ -1552,9 +1552,9 @@ static int oxp_hid_probe(struct hid_device *hdev,
> >
> >  static void oxp_hid_remove(struct hid_device *hdev)
> >  {
> > -     cancel_delayed_work(&drvdata.oxp_rgb_queue);
> > -     cancel_delayed_work(&drvdata.oxp_btn_queue);
> > -     cancel_delayed_work(&drvdata.oxp_mcu_init);
> > +     disable_delayed_work_sync(&drvdata.oxp_rgb_queue);
> > +     disable_delayed_work_sync(&drvdata.oxp_btn_queue);
> > +     disable_delayed_work_sync(&drvdata.oxp_mcu_init);
> >       hid_hw_close(hdev);
> >       hid_hw_stop(hdev);
> >  }
> >
> > ---
>
> Hi Dmitry,
>
> Thanks again for the v1 review. Sashiko's v2 review raised two points I
> want to act on:
>
> 1. "Uninitialized work struct access during early raw events" -- agreed.
>    v2 moved INIT_DELAYED_WORK(&drvdata.oxp_mcu_init) to the end of
>    oxp_cfg_probe(), widening the window in which an early status report
>    could mod_delayed_work() a not-yet-initialized (zeroed) work. I'll
>    fix this in v3 by keeping INIT_DELAYED_WORK() before
>    devm_device_add_group() and moving only the mod_delayed_work() after
>    it: the work is then initialized before any raw event can arm it,
>    while a probe failure still can't leave it armed.
>
Hi Shengzhuo,

I dealt with this when writing the hid-msi drivers as well, and
Sashiko will continuously come up with new issues for each revision.
The next issue is going to be that the attributes are initialized
before the setup function has run to query the device after the MCU
will accept messages. The solution I found was to move
devm_device_add_group to the end of the init work queue once the query
has been completed, then inform sysfs with a `change` uevent. Perhaps
that pattern will be useful here.

For ease of reviewing, below is the cfg_setup_fn from that driver

> 2. "Global workqueues permanently disabled on inert interface removal."
>    The driver keeps all state in a single static global drvdata, and
>    module_hid_driver() binds it to every interface of the device, so
>    oxp_hid_remove() runs when any interface is unbound. With
>    disable_delayed_work_sync() and no enable_delayed_work() anywhere,
>    unbinding an inert interface disables the works for the still-bound
>    gamepad interface. cancel_delayed_work_sync() (v1) re-enabled them,
>    so it didn't have this side effect.
>
>    This looks like a symptom of the static-global-drvdata issue rather
>    than disable_delayed_work_sync() itself -- with per-device drvdata
>    each interface would have its own works. Before I send v3, would you
>    prefer to keep disable_delayed_work_sync() (and address the
>    multi-interface case via the per-device drvdata refactor you
>    mentioned as a separate patch), or go back to
>    cancel_delayed_work_sync()? I'll hold v3 until I hear from you.
>

I had planned on devm_alloc the drvdata per device once the msi
drivers are done. If you are willing to take that on I'll be glad to
test with my F1 Pro. Out of curiosity, do you have a device available
to test as well? If so, which model do you have? I can ask the
community to test on any device family that isn't covered.

To your question, I don't think the bug fix switching to
disable_delayed_work_sync is worth the side effects without first
addressing the global drvdata issue. That would introduce a true
regression to fix a theoretical logic bug. I would rather you either
switch to the devm_alloc drvdata first or hold that change until I'm
able to do it later myself.

Thanks,
Derek

---

static void cfg_setup_fn(struct work_struct *work)
{
    struct delayed_work *dwork = container_of(work, struct delayed_work, work);
    struct claw_drvdata *drvdata = container_of(dwork, struct
claw_drvdata, cfg_setup);
    bool gamepad_ready = false, rgb_ready = false, gp_registered,
rgb_registered;
    int ret;

    ret = claw_hw_output_report(drvdata->hdev,
CLAW_COMMAND_TYPE_READ_GAMEPAD_MODE,
                    NULL, 0, 25);
    if (ret) {
        dev_err(&drvdata->hdev->dev,
            "Failed to read gamepad mode: %d\n", ret);
        goto prep_rgb;
    }
    gamepad_ready = true;

prep_rgb:
    ret = claw_read_rgb_config(drvdata->hdev);
    if (ret) {
        dev_err(&drvdata->hdev->dev,
            "Failed to read RGB config: %d\n", ret);
        goto try_gamepad;
    }
    rgb_ready = true;

    /* Add sysfs attributes after we get the device state */
try_gamepad:
    scoped_guard(spinlock_irqsave, &drvdata->registration_lock)
        /* Pairs with smp_store_release from below */
        gp_registered = smp_load_acquire(&drvdata->gp_registered);

    if (!gp_registered && gamepad_ready) {
        ret = device_add_group(&drvdata->hdev->dev, &claw_gamepad_attr_group);
        if (ret) {
            dev_err(&drvdata->hdev->dev,
                "Failed to create gamepad attrs: %d\n", ret);
            goto try_rgb;
        }

        scoped_guard(spinlock_irqsave, &drvdata->registration_lock) {
            /* Pairs with smp_load_acquire in attribute show/store functions */
            smp_store_release(&drvdata->gp_registered, true);
            gp_registered = true;
        }
    }

try_rgb:
    /* Add and enable RGB interface once we have the device state */
    scoped_guard(spinlock_irqsave, &drvdata->registration_lock)
        /* Pairs with smp_store_release from below */
        rgb_registered = smp_load_acquire(&drvdata->rgb_registered);

    if (!rgb_registered && rgb_ready) {
        ret = led_classdev_multicolor_register(&drvdata->hdev->dev,
                               &drvdata->led_mc);
        if (ret) {
            dev_err(&drvdata->hdev->dev,
                "Failed to create led device: %d\n", ret);
            goto update_kobjects;
        }

        ret = device_add_group(drvdata->led_mc.led_cdev.dev,
&claw_rgb_attr_group);
        if (ret) {
            dev_err(&drvdata->hdev->dev,
                "Failed to create RGB attrs: %d\n", ret);
            led_classdev_multicolor_unregister(&drvdata->led_mc);
            goto update_kobjects;
        }

        scoped_guard(spinlock_irqsave, &drvdata->registration_lock) {
            /* Pairs with smp_load_acquire in attribute show/store functions */
            smp_store_release(&drvdata->rgb_registered, true);
            rgb_registered = true;
        }
    }

update_kobjects:
    if (gp_registered)
        kobject_uevent(&drvdata->hdev->dev.kobj, KOBJ_CHANGE);
    if (rgb_registered)
        kobject_uevent(&drvdata->led_mc.led_cdev.dev->kobj, KOBJ_CHANGE);
}
> The remaining sashiko items look pre-existing and outside this fix.
>
> Thanks,
> Shengzhuo

Re: [PATCH v2] HID: hid-oxp: fix UAF on pending work in remove()

[Dmitry Torokhov]

On Tue, Aug 04, 2026 at 02:24:14PM -0700, Derek John Clark wrote:
> On Tue, Aug 4, 2026 at 1:06 PM Shengzhuo Wei <me@cherr.cc> wrote:
> >
> > On 2026-08-04 17:50, Shengzhuo Wei wrote:
> > > ---
> > >  drivers/hid/hid-oxp.c | 12 ++++++------
> > >  1 file changed, 6 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/hid/hid-oxp.c b/drivers/hid/hid-oxp.c
> > > index 20a54f337220dc2aee3483a14d542b66c487bd60..abd622ff1b26b312ad9c8a4375822832f8371533 100644
> > > --- a/drivers/hid/hid-oxp.c
> > > +++ b/drivers/hid/hid-oxp.c
> > > @@ -1501,14 +1501,14 @@ static int oxp_cfg_probe(struct hid_device *hdev, u16 up)
> > >       drvdata.gamepad_mode = OXP_GP_MODE_XINPUT;
> > >       drvdata.rumble_intensity = 5;
> > >
> > > -     INIT_DELAYED_WORK(&drvdata.oxp_mcu_init, oxp_mcu_init_fn);
> > > -     mod_delayed_work(system_wq, &drvdata.oxp_mcu_init, msecs_to_jiffies(50));
> > > -
> > >       ret = devm_device_add_group(&hdev->dev, &oxp_cfg_attrs_group);
> > >       if (ret)
> > >               return dev_err_probe(&hdev->dev, ret,
> > >                                    "Failed to attach configuration attributes\n");
> > >
> > > +     INIT_DELAYED_WORK(&drvdata.oxp_mcu_init, oxp_mcu_init_fn);
> > > +     mod_delayed_work(system_wq, &drvdata.oxp_mcu_init, msecs_to_jiffies(50));
> > > +
> > >       return 0;
> > >  }
> > >
> > > @@ -1552,9 +1552,9 @@ static int oxp_hid_probe(struct hid_device *hdev,
> > >
> > >  static void oxp_hid_remove(struct hid_device *hdev)
> > >  {
> > > -     cancel_delayed_work(&drvdata.oxp_rgb_queue);
> > > -     cancel_delayed_work(&drvdata.oxp_btn_queue);
> > > -     cancel_delayed_work(&drvdata.oxp_mcu_init);
> > > +     disable_delayed_work_sync(&drvdata.oxp_rgb_queue);
> > > +     disable_delayed_work_sync(&drvdata.oxp_btn_queue);
> > > +     disable_delayed_work_sync(&drvdata.oxp_mcu_init);
> > >       hid_hw_close(hdev);
> > >       hid_hw_stop(hdev);
> > >  }
> > >
> > > ---
> >
> > Hi Dmitry,
> >
> > Thanks again for the v1 review. Sashiko's v2 review raised two points I
> > want to act on:
> >
> > 1. "Uninitialized work struct access during early raw events" -- agreed.
> >    v2 moved INIT_DELAYED_WORK(&drvdata.oxp_mcu_init) to the end of
> >    oxp_cfg_probe(), widening the window in which an early status report
> >    could mod_delayed_work() a not-yet-initialized (zeroed) work. I'll
> >    fix this in v3 by keeping INIT_DELAYED_WORK() before
> >    devm_device_add_group() and moving only the mod_delayed_work() after
> >    it: the work is then initialized before any raw event can arm it,
> >    while a probe failure still can't leave it armed.
> >
> Hi Shengzhuo,
> 
> I dealt with this when writing the hid-msi drivers as well, and
> Sashiko will continuously come up with new issues for each revision.

Yes, so we do not require patch submitters to act on all Sashiko
findings (and quite often they are not right), especially pre-existing
ones. So feel free to ignore this.

For this particular instance maybe simply drop this change from v3: it
is all broken anyways. The driver should initialize all internal
structures (work items, lock, etc) beforehand and then start configuring
the behavior since events can be coming in at any moment.

And on probe error it should try to clean up everything (again, on the

> The next issue is going to be that the attributes are initialized
> before the setup function has run to query the device after the MCU
> will accept messages. The solution I found was to move
> devm_device_add_group to the end of the init work queue once the query
> has been completed, then inform sysfs with a `change` uevent. Perhaps
> that pattern will be useful here.
> 
> For ease of reviewing, below is the cfg_setup_fn from that driver
> 
> > 2. "Global workqueues permanently disabled on inert interface removal."
> >    The driver keeps all state in a single static global drvdata, and
> >    module_hid_driver() binds it to every interface of the device, so
> >    oxp_hid_remove() runs when any interface is unbound. With
> >    disable_delayed_work_sync() and no enable_delayed_work() anywhere,
> >    unbinding an inert interface disables the works for the still-bound
> >    gamepad interface. cancel_delayed_work_sync() (v1) re-enabled them,
> >    so it didn't have this side effect.
> >
> >    This looks like a symptom of the static-global-drvdata issue rather
> >    than disable_delayed_work_sync() itself -- with per-device drvdata
> >    each interface would have its own works. Before I send v3, would you
> >    prefer to keep disable_delayed_work_sync() (and address the
> >    multi-interface case via the per-device drvdata refactor you
> >    mentioned as a separate patch), or go back to
> >    cancel_delayed_work_sync()? I'll hold v3 until I hear from you.
> >

Yes, so feel free to ignore Sashiko or (if you have spare cycles)
address this global instance in a separate patch at some later time.

> 
> I had planned on devm_alloc the drvdata per device once the msi
> drivers are done. If you are willing to take that on I'll be glad to
> test with my F1 Pro. Out of curiosity, do you have a device available
> to test as well? If so, which model do you have? I can ask the
> community to test on any device family that isn't covered.
> 
> To your question, I don't think the bug fix switching to
> disable_delayed_work_sync is worth the side effects without first
> addressing the global drvdata issue. That would introduce a true
> regression to fix a theoretical logic bug. I would rather you either
> switch to the devm_alloc drvdata first or hold that change until I'm
> able to do it later myself.

If there is possibility to have multiple instances then this driver is
FUBAR in the current shape: one device instance fires up work items for
another device. So holding the patch makes no sense IMO.

Thanks.

-- 
Dmitry

Re: [PATCH v2] HID: hid-oxp: fix UAF on pending work in remove()

[Shengzhuo Wei]

Hi Derek, Dmitry,

Derek wrote:
> Out of curiosity, do you have a device available to test as well? If
> so, which model do you have?

I don't have any OneXPlayer hardware. I found this bug by creating a
gen2 OXP device through /dev/uhid and tearing it down under KASAN in
QEMU, not on a real device, and I'm not deeply familiar with the HID
subsystem overall.

On disable_delayed_work_sync() I seem to be caught between your two
positions. Derek:

> I don't think the bug fix switching to disable_delayed_work_sync is
> worth the side effects without first addressing the global drvdata
> issue. That would introduce a true regression to fix a theoretical
> logic bug. I would rather you either switch to the devm_alloc drvdata
> first or hold that change until I'm able to do it later myself.

Dmitry:

> If there is possibility to have multiple instances then this driver is
> FUBAR in the current shape: one device instance fires up work items
> for another device. So holding the patch makes no sense IMO.

I'm not well placed to own the per-device drvdata refactor: I have no
hardware to validate the multi-interface behavior, and I don't have the
HID-subsystem familiarity to do that rework confidently. So I'd rather
not take that piece on.

Given that, what would you like me to do? The realistic contribution I
can stand behind is a minimal v3 that only fixes the use-after-free I
actually found and verified -- cancel_delayed_work() ->
cancel_delayed_work_sync() in oxp_hid_remove() (the v1 approach),
reverting v2's probe change and dropping disable_delayed_work_sync().
It's KASAN-verified, introduces no regression, and needs no hardware.
The re-arm hardening and the drvdata/attr-ordering rework would then be
Derek's, on real hardware with the hid-msi pattern.

If you'd rather I drop the patch entirely and leave the whole thing
(including the cancel_delayed_work_sync part) to Derek, that's fine
too. I'd like to land this fix if there's a version of it you'd accept
from me, but I defer to your judgment on scope -- I just didn't want to
silently walk away from a bug I reported.

Thanks,
Shengzhuo