On Tue, Jul 21, 2020 at 10:16:37AM +0300, Dan Carpenter wrote: > 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. Ah...I thought `Reply-To` and `In-Reply-To` are the same thing...Sorry for the beginner's mistake... > 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. I see, I will stop guessing and wait for the maintainers' feedback. Thank you, Peilin Ye
