From: sashiko-bot@kernel.org
To: "Jeffin Philip" <jeffinphilip14@gmail.com>
Cc: dmitry.torokhov@gmail.com, linux-input@vger.kernel.org
Subject: Re: [syzbot] [input?] KASAN: slab-use-after-free Read in atkbd_set_repeat_rate
Date: Fri, 28 Aug 2026 13:13:51 +0000 [thread overview]
Message-ID: <20260828131351.C3F011F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260828125430.11470-1-jeffinphilip14@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Unconditional acquisition of `atkbd->mutex` in `atkbd_disable()` causes an AA self-deadlock because callers already hold this mutex.
- [Low] Passing `struct mutex` by value instead of a pointer to the `guard(mutex)` macro causes a build failure.
--
commit ea5b33bff452dfd0c6a1ded0647c9fed571513f0
Author: Jeffin Philip <jeffinphilip14@gmail.com>
KASAN: slab-use-after-free Read in atkbd_set_repeat_rate
This commit adds a mutex guard to atkbd_disable() to prevent a
use-after-free issue detected by KASAN in atkbd_set_repeat_rate.
A syzkaller test case is referenced in the commit message.
> diff --git a/drivers/input/keyboard/atkbd.c b/drivers/input/keyboard/atkbd.c
> index 3509b58e64920..82157782e166f 100644
> --- a/drivers/input/keyboard/atkbd.c
> +++ b/drivers/input/keyboard/atkbd.c
> @@ -706,6 +706,7 @@ static inline void atkbd_enable(struct atkbd *atkbd)
>
> static inline void atkbd_disable(struct atkbd *atkbd)
> {
> + guard(mutex)(atkbd->mutex);
[Severity: Low]
Does this compile? The guard(mutex) macro expects a pointer to the mutex,
but it looks like we are passing the struct by value here instead of using
the address-of operator (&atkbd->mutex).
[Severity: High]
Does acquiring the mutex here cause a self-deadlock?
Looking at atkbd_reconnect() and atkbd_attr_set_helper(), they already acquire
the mutex before calling atkbd_disable():
drivers/input/keyboard/atkbd.c:atkbd_reconnect() {
...
guard(mutex)(&atkbd->mutex);
atkbd_disable(atkbd);
...
}
drivers/input/keyboard/atkbd.c:atkbd_attr_set_helper() {
...
scoped_guard(mutex_intr, &atkbd->mutex) {
atkbd_disable(atkbd);
...
}
Since mutexes are not recursive, wouldn't unconditional acquisition here
cause a thread hang when a user modifies a sysfs attribute or triggers a
reconnect?
> guard(serio_pause_rx)(atkbd->ps2dev.serio);
>
> atkbd->enabled = false;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260828125430.11470-1-jeffinphilip14@gmail.com?part=1
next prev parent reply other threads:[~2026-08-28 13:13 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-28 0:44 [syzbot] [input?] KASAN: slab-use-after-free Read in atkbd_set_repeat_rate syzbot
2026-08-28 11:42 ` syzbot
2026-08-28 12:54 ` Jeffin Philip
2026-08-28 13:03 ` syzbot
2026-08-28 13:13 ` sashiko-bot [this message]
2026-08-28 13:41 ` Jeffin Philip
2026-08-28 13:52 ` sashiko-bot
2026-08-28 14:06 ` syzbot
2026-08-28 14:03 ` Jeffin Philip
2026-08-28 14:15 ` sashiko-bot
2026-08-28 14:20 ` syzbot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260828131351.C3F011F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dmitry.torokhov@gmail.com \
--cc=jeffinphilip14@gmail.com \
--cc=linux-input@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox