Re: [syzbot] [input?] KASAN: slab-use-after-free Read in atkbd_set_repeat_rate

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Using an interruptible lock guard (`scoped_guard(mutex_intr)`) in a teardown path conditionally skips the device disable logic if a signal is pending, resulting in a Use-After-Free of `atkbd->dev`.
--

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

KASAN: slab-use-after-free Read in atkbd_set_repeat_rate

This commit attempts to fix a use-after-free issue by wrapping the
device disable routine in atkbd_disconnect with a mutex guard to serialize
teardown against other event and attribute operations.

> diff --git a/drivers/input/keyboard/atkbd.c b/drivers/input/keyboard/atkbd.c
> index 3509b58e64920..d5b564bab0e20 100644
> --- a/drivers/input/keyboard/atkbd.c
> +++ b/drivers/input/keyboard/atkbd.c
> @@ -961,7 +961,9 @@ static void atkbd_disconnect(struct serio *serio)
>  {
>  	struct atkbd *atkbd = atkbd_from_serio(serio);
>  
> +	scoped_guard(mutex_intr, &atkbd->mutex) {
>  	atkbd_disable(atkbd);
> +	}

[Severity: High]
If a signal is pending when atkbd_disconnect() is called, will this scoped
guard silently skip the hardware disable block?

Because mutex_intr is interruptible, it returns -EINTR if the process
receives a signal (such as when userspace sends a signal to the unbind
process). This causes the guarded scope block to be bypassed, meaning
atkbd_disable() is not executed and atkbd->enabled remains true.

When input_unregister_device() subsequently frees the device, could
concurrent handlers that rely on the enabled flag still execute and trigger
a use-after-free on the freed dev pointer?

For example, in atkbd_receive_byte():

	if (!atkbd->enabled)
		return;

	input_event(dev, EV_MSC, MSC_RAW, code);

And similarly in atkbd_event_work():

	if (test_and_clear_bit(ATKBD_REP_EVENT_BIT, &atkbd->event_mask))
		atkbd_set_repeat_rate(atkbd);

Should this use an uninterruptible guard instead, since disabling the device
is a mandatory step during teardown?

>  
>  	input_unregister_device(atkbd->dev);
>

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