Re: [PATCH v4] Input: atkbd - fix uaf in atkbd_set_repeat_rate

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The patch fails to resolve the Use-After-Free (UAF) race condition it intends to fix because `disable_delayed_work_sync()` is incorrectly placed after `input_unregister_device()`.
--

commit 364595b57a843b20a975005b27712754f014825e
Author: Jeffin Philip <jeffinphilip14@gmail.com>

Input: atkbd - fix uaf in atkbd_set_repeat_rate
    
atkbd_disable() marks atkbd as disabled to prevent any work
event to be executed, however this can race with atkbd_event_work().
If a pending work passes the atkbd->enabled check and atkbd_disable()
runs after in disconnect, it could dereference dev which is freed in
disconnect following atkbd being marked disabled. Fix this by adding
disable_delayed_work_sync() which drops all work events preventing
any rescheduling after atkbd is marked disabled.
    
Reported-by: syzbot+1e2ef9bcb29af666b2e6@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=1e2ef9bcb29af666b2e6
Fixes: 0ef7a26af127 ("Input: atkbd - fix canceling event_work in disconnect")
Signed-off-by: Jeffin Philip <jeffinphilip14@gmail.com>

> diff --git a/drivers/input/keyboard/atkbd.c b/drivers/input/keyboard/atkbd.c
> index 3509b58e64920..0d75a7ba48d3c 100644
> --- a/drivers/input/keyboard/atkbd.c
> +++ b/drivers/input/keyboard/atkbd.c
> @@ -966,12 +966,9 @@ static void atkbd_disconnect(struct serio *serio)
>  	input_unregister_device(atkbd->dev);
>  
>  	/*
> -	 * Make sure we don't have a command in flight.
> -	 * Note that since atkbd->enabled is false event work will keep
> -	 * rescheduling itself until it gets canceled and will not try
> -	 * accessing freed input device or serio port.
> +	 * Prevent work from being rescheduled after atkbd is marked disabled
>  	 */
> -	cancel_delayed_work_sync(&atkbd->event_work);
> +	disable_delayed_work_sync(&atkbd->event_work);

[Severity: High]
This isn't a bug introduced by this patch, but does calling
disable_delayed_work_sync() after input_unregister_device() leave a
Use-After-Free race window open for the background work?

If atkbd_event_work() executes concurrently with atkbd_disconnect() and
passes the atkbd->enabled check, it can access atkbd->dev after it has
been freed.

For example, if atkbd_disconnect() calls input_unregister_device(atkbd->dev)
which drops the last reference and frees the device, the background work
could then access the freed dev in atkbd_set_leds():

drivers/input/keyboard/atkbd.c:atkbd_set_leds() {
    ...
	param[0] = (test_bit(LED_SCROLLL, dev->led) ? 1 : 0)
    ...
}

Should disable_delayed_work_sync() be moved above input_unregister_device()
to fully close this race window and ensure the work item cannot execute
after the device is freed?

>  
>  	serio_close(serio);
>  	serio_set_drvdata(serio, NULL);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260829135959.14882-1-jeffinphilip14@gmail.com?part=1