From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
Henrik Rydberg <rydberg@bitmath.org>,
"linux-input@vger.kernel.org" <linux-input@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH (resend)] Input: MT - limit max slots
Date: Mon, 29 Jul 2024 16:17:00 -0700 [thread overview]
Message-ID: <Zqgi7NYEbpRsJfa2@google.com> (raw)
In-Reply-To: <CAHk-=whH+xp7ZxqgwOEm=_H=fVpWQvWpPqK6gzcPt8xdEXzwrg@mail.gmail.com>
On Mon, Jul 29, 2024 at 01:14:36PM -0700, Linus Torvalds wrote:
> On Mon, 29 Jul 2024 at 13:00, Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> >
> > Hmm, maybe the checks should go into drivers/input/misc/uinput.c which
> > is the only place that allows userspace to create input device instances
> > and drive them rather than into input core logic because all other
> > devices are backed by real hardware.
>
> Ack, that sounds like a good idea, particularly if there is some
> single location that could validate the input.
>
> uinput_validate_absinfo(), perhaps?
Yes, I think that's the right place.
>
> We do end up trying to protect against some forms of bad hardware too
> when possible, but realistically _that_ kind of protection should be
> more along the lines of "don't cause security issues".
Most of them have statically defined slot limit. The exception is HID
(which can also be fed garbage through uhid) but hid-multitouch uses u8
for maximum number of contacts, so can't go above 256.
Thanks.
--
Dmitry
---8<------------------8<------------------8<---------------
Input: uinput - reject requests with unreasonable number of slots
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
When exercising uinput interface syzkaller may try setting up device
with a really large number of slots, which causes memory allocation
failure in input_mt_init_slots(). While this allocation failure is
handled properly and request is rejected, it results in syzkaller
reports. Additionally, such request may put undue burden on the
system which will try to free a lot of memory for a bogus request.
Fix it by limiting allowed number of slots to 100. This can easily
be extended if we see devices that can track more than 100 contacts.
Reported-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Reported-by: syzbot <syzbot+0122fa359a69694395d5@syzkaller.appspotmail.com>
Closes: https://syzkaller.appspot.com/bug?extid=0122fa359a69694395d5
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/input/misc/uinput.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/input/misc/uinput.c b/drivers/input/misc/uinput.c
index d23f3225b00f..ea3d34e62eb2 100644
--- a/drivers/input/misc/uinput.c
+++ b/drivers/input/misc/uinput.c
@@ -417,6 +417,20 @@ static int uinput_validate_absinfo(struct input_dev *dev, unsigned int code,
return -EINVAL;
}
+ /*
+ * Limit number of contacts to a reasonable value (100). This
+ * ensures that we need less than 2 pages for struct input_mt
+ * (we are not using in-kernel slot assignment so not going to
+ * allocate memory for the "red" table), and we should have no
+ * trouble getting this much memory.
+ */
+ if (code == ABS_MT_SLOT && max > 99) {
+ printk(KERN_DEBUG
+ "%s: unreasonably large number of slots requested: %d\n",
+ UINPUT_NAME, max);
+ return -EINVAL;
+ }
+
return 0;
}
next prev parent reply other threads:[~2024-07-29 23:17 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-29 12:51 [PATCH (resend)] Input: MT - limit max slots Tetsuo Handa
2024-07-29 13:05 ` Greg Kroah-Hartman
2024-07-29 13:15 ` Tetsuo Handa
2024-07-29 14:28 ` Greg Kroah-Hartman
2024-07-29 15:57 ` Dmitry Torokhov
2024-07-29 17:43 ` Linus Torvalds
2024-07-29 17:59 ` Dmitry Torokhov
2024-07-29 18:16 ` Linus Torvalds
2024-07-29 18:35 ` Dmitry Torokhov
2024-07-29 18:41 ` Linus Torvalds
2024-07-29 19:12 ` Dmitry Torokhov
2024-07-29 19:27 ` Linus Torvalds
2024-07-29 20:00 ` Dmitry Torokhov
2024-07-29 20:14 ` Linus Torvalds
2024-07-29 23:17 ` Dmitry Torokhov [this message]
2024-07-30 5:38 ` Tetsuo Handa
2024-07-30 21:52 ` Dmitry Torokhov
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=Zqgi7NYEbpRsJfa2@google.com \
--to=dmitry.torokhov@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=rydberg@bitmath.org \
--cc=torvalds@linux-foundation.org \
/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;
as well as URLs for NNTP newsgroup(s).