From: Dan Carpenter <dan.carpenter@oracle.com>
To: Peilin Ye <yepeilin.cs@gmail.com>
Cc: Jiri Kosina <jikos@kernel.org>,
Benjamin Tissoires <benjamin.tissoires@redhat.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
syzkaller-bugs@googlegroups.com,
linux-kernel-mentees@lists.linuxfoundation.org,
linux-usb@vger.kernel.org, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [Linux-kernel-mentees] [PATCH v1] usbhid: Fix slab-out-of-bounds write in hiddev_ioctl_usage()
Date: Tue, 21 Jul 2020 10:16:37 +0300 [thread overview]
Message-ID: <20200721071637.GK2571@kadam> (raw)
In-Reply-To: <20200720191656.GA3366@PWN>
For some reason the reply-to header on your email is bogus:
Reply-To: 20200720121257.GJ2571@kadam
"kadam" is a system on my home network.
On Mon, Jul 20, 2020 at 03:16:56PM -0400, Peilin Ye wrote:
> I made some mistakes in the previous e-mail. Please ignore that. There
> are a lot of things going on...Sorry for that.
>
> On Mon, Jul 20, 2020 at 03:12:57PM +0300, Dan Carpenter wrote:
> > So another option would be to just add HIDIOCGUSAGE and HIDIOCSUSAGE to
> > the earlier check. That risks breaking userspace. Another option is to
> > just add a check like you did earlier to the HIDIOCGUSAGE case.
> > Probably just do option #2 and resend.
>
> Sure, I will just add the same check to the HIDIOCGUSAGE case for the
> time being. Thank you for the detailed explanation.
>
> Here's what I found after digging a bit further though:
>
> hid_open_report() calls different functions in order to process
> different type of items:
>
> drivers/hid/hid-core.c:1193:
>
> static int (*dispatch_type[])(struct hid_parser *parser,
> struct hid_item *item) = {
> hid_parser_main,
> hid_parser_global,
> hid_parser_local,
> hid_parser_reserved
> };
>
> In this case, hid_parser_main() calls hid_add_field(), which in turn
> calls hid_register_field(), which allocates the `field` object as you
> mentioned:
>
> drivers/hid/hid-core.c:102:
>
> field = kzalloc((sizeof(struct hid_field) +
> usages * sizeof(struct hid_usage) +
> values * sizeof(unsigned)), GFP_KERNEL);
Yeah. And in the caller it does:
drivers/hid/hid-core.c
297 if (!parser->local.usage_index) /* Ignore padding fields */
298 return 0;
299
300 usages = max_t(unsigned, parser->local.usage_index,
^^^^^^^^^^^^^^
301 parser->global.report_count);
302
303 field = hid_register_field(report, usages, parser->global.report_count);
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
So ->usages is always greater or equal to ->global.report_count.
304 if (!field)
305 return 0;
306
307 field->physical = hid_lookup_collection(parser, HID_COLLECTION_PHYSICAL);
>
> Here, `values` equals to `global.report_count`. See how it is being
> called:
>
> drivers/hid/hid-core.c:303:
>
> field = hid_register_field(report, usages, parser->global.report_count);
>
> In hid_open_report(), `global.report_count` can be set by calling
> hid_parser_global().
>
> However, the syzkaller reproducer made hid_open_report() to call
> hid_parser_main() __before__ `global.report_count` is properly set. It's
> zero. So hid_register_field() allocated `field` with `values` equals to
> zero - No room for value[] at all. I believe this caused the bug.
I don't know if zero is valid or not. I suspect it is valid. We have
no reason to think that it's invalid.
regards,
dan carpenter
next prev parent reply other threads:[~2020-07-21 7:16 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-18 23:12 [Linux-kernel-mentees] [PATCH v1] usbhid: Fix slab-out-of-bounds write in hiddev_ioctl_usage() Peilin Ye
2020-07-20 11:54 ` Dan Carpenter
2020-07-20 12:12 ` Dan Carpenter
2020-07-20 19:05 ` Peilin Ye
2020-07-20 19:16 ` Peilin Ye
2020-07-21 7:16 ` Dan Carpenter [this message]
2020-07-21 8:27 ` Greg Kroah-Hartman
2020-07-21 8:39 ` Dan Carpenter
2020-07-21 8:39 ` Peilin Ye
2020-07-20 19:52 ` [Linux-kernel-mentees] [PATCH v2] " Peilin Ye
2020-07-23 14:51 ` Dan Carpenter
2020-07-29 11:37 ` [Linux-kernel-mentees] [PATCH v2 RESEND] " Peilin Ye
2020-07-29 14:35 ` Dan Carpenter
2020-08-17 10:21 ` Jiri Kosina
2020-08-18 10:00 ` Peilin Ye
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=20200721071637.GK2571@kadam \
--to=dan.carpenter@oracle.com \
--cc=benjamin.tissoires@redhat.com \
--cc=gregkh@linuxfoundation.org \
--cc=jikos@kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel-mentees@lists.linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=syzkaller-bugs@googlegroups.com \
--cc=yepeilin.cs@gmail.com \
/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).