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] Double-lock self-deadlock on `atkbd->mutex` in `atkbd_enable` and `atkbd_disable` when called from `atkbd_reconnect` and `atkbd_attr_set_helper`.
--

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

KASAN: slab-use-after-free Read in atkbd_set_repeat_rate
    
This commit adds mutex guards in atkbd_enable() and atkbd_disable() to
presumably protect against concurrent access.

> diff --git a/drivers/input/keyboard/atkbd.c b/drivers/input/keyboard/atkbd.c
> index 3509b58e64920..f7c71278ecaa4 100644
> --- a/drivers/input/keyboard/atkbd.c
> +++ b/drivers/input/keyboard/atkbd.c
> @@ -694,6 +694,7 @@ static int atkbd_event(struct input_dev *dev,
>  
>  static inline void atkbd_enable(struct atkbd *atkbd)
>  {
> +	guard(mutex)(&atkbd->mutex);
>  	guard(serio_pause_rx)(atkbd->ps2dev.serio);
>  
>  	atkbd->enabled = true;
> @@ -706,6 +707,7 @@ static inline void atkbd_enable(struct atkbd *atkbd)
>  
>  static inline void atkbd_disable(struct atkbd *atkbd)
>  {
> +	guard(mutex)(&atkbd->mutex);

[Severity: High]
Does this code cause a self-deadlock when called from paths that already
hold atkbd->mutex?

For example, when the system resumes and atkbd_reconnect() is called, the
mutex is acquired right before calling atkbd_disable():

drivers/input/keyboard/atkbd.c:atkbd_reconnect() {
...
	guard(mutex)(&atkbd->mutex);

	atkbd_disable(atkbd);
...
}

Similarly, writing to a sysfs attribute triggers atkbd_attr_set_helper(),
which acquires the lock before calling both atkbd_disable() and
atkbd_enable():

drivers/input/keyboard/atkbd.c:atkbd_attr_set_helper() {
...
	scoped_guard(mutex_intr, &atkbd->mutex) {
		atkbd_disable(atkbd);
		retval = handler(atkbd, buf, count);
		atkbd_enable(atkbd);
...
}

Since struct mutex is not recursive, attempting to acquire an already-held
mutex here will cause the thread to hang.

>  	guard(serio_pause_rx)(atkbd->ps2dev.serio);
>  
>  	atkbd->enabled = false;

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