| Message ID | alpine.LNX.2.00.1308282159590.22181@pobox.suse.cz (mailing list archive) |
|---|---|
| State | New, archived |
| Delegated to: | Jiri Kosina |
| Headers | show |
On Wed, Aug 28, 2013 at 10:30 PM, Jiri Kosina <jkosina@suse.cz> wrote: > From: Kees Cook <keescook@chromium.org> > > This driver must validate the availability of the HID output report and > its size before it can write LED states via buzz_set_leds(). This stops > a heap overflow that is possible if a device provides a malicious HID > output report: > > [ 108.171280] usb 1-1: New USB device found, idVendor=054c, idProduct=0002 > ... > [ 117.507877] BUG kmalloc-192 (Not tainted): Redzone overwritten > > CVE-2013-2890 > > Signed-off-by: Kees Cook <keescook@chromium.org> > Cc: stable@kernel.org > --- > drivers/hid/hid-sony.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/drivers/hid/hid-sony.c b/drivers/hid/hid-sony.c > index 87fbe29..b987926 100644 > --- a/drivers/hid/hid-sony.c > +++ b/drivers/hid/hid-sony.c > @@ -537,6 +537,10 @@ static int buzz_init(struct hid_device *hdev) > drv_data = hid_get_drvdata(hdev); > BUG_ON(!(drv_data->quirks & BUZZ_CONTROLLER)); > > + /* Validate expected report characteristics. */ > + if (!hid_validate_report(hdev, HID_OUTPUT_REPORT, 0, 1, 7)) I don't have access to the device anymore, but I still kept the report descriptors (this is the interesting part): 0xa1, 0x02, // Collection (Logical) 60 0x75, 0x08, // Report Size (8) 62 0x95, 0x07, // Report Count (7) 64 0x46, 0xff, 0x00, // Physical Maximum (255) 66 0x26, 0xff, 0x00, // Logical Maximum (255) 69 0x09, 0x02, // Usage (Vendor Usage 2) 72 0x91, 0x02, // Output (Data,Var,Abs) 74 0xc0, // End Collection 76 So with the current implementation of hid_validate_report(), it works, but if another Buzz controller show up at some point with extras fields in this output report... we will be screwed. So please, amend hid_validate_report(), or specifically test here that the LED output report is 7 bytes. Cheers, Benjamin > + return -ENODEV; > + > buzz = kzalloc(sizeof(*buzz), GFP_KERNEL); > if (!buzz) { > hid_err(hdev, "Insufficient memory, cannot allocate driver data\n"); > > -- > Jiri Kosina > SUSE Labs > -- > To unsubscribe from this list: send the line "unsubscribe linux-input" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Aug 29, 2013 at 2:48 AM, Benjamin Tissoires <benjamin.tissoires@gmail.com> wrote: > On Wed, Aug 28, 2013 at 10:30 PM, Jiri Kosina <jkosina@suse.cz> wrote: >> From: Kees Cook <keescook@chromium.org> >> >> This driver must validate the availability of the HID output report and >> its size before it can write LED states via buzz_set_leds(). This stops >> a heap overflow that is possible if a device provides a malicious HID >> output report: >> >> [ 108.171280] usb 1-1: New USB device found, idVendor=054c, idProduct=0002 >> ... >> [ 117.507877] BUG kmalloc-192 (Not tainted): Redzone overwritten >> >> CVE-2013-2890 >> >> Signed-off-by: Kees Cook <keescook@chromium.org> >> Cc: stable@kernel.org >> --- >> drivers/hid/hid-sony.c | 4 ++++ >> 1 file changed, 4 insertions(+) >> >> diff --git a/drivers/hid/hid-sony.c b/drivers/hid/hid-sony.c >> index 87fbe29..b987926 100644 >> --- a/drivers/hid/hid-sony.c >> +++ b/drivers/hid/hid-sony.c >> @@ -537,6 +537,10 @@ static int buzz_init(struct hid_device *hdev) >> drv_data = hid_get_drvdata(hdev); >> BUG_ON(!(drv_data->quirks & BUZZ_CONTROLLER)); >> >> + /* Validate expected report characteristics. */ >> + if (!hid_validate_report(hdev, HID_OUTPUT_REPORT, 0, 1, 7)) > > I don't have access to the device anymore, but I still kept the report > descriptors (this is the interesting part): > > 0xa1, 0x02, // Collection (Logical) 60 > 0x75, 0x08, // Report Size (8) 62 > 0x95, 0x07, // Report Count (7) 64 > 0x46, 0xff, 0x00, // Physical Maximum (255) 66 > 0x26, 0xff, 0x00, // Logical Maximum (255) 69 > 0x09, 0x02, // Usage (Vendor Usage 2) 72 > 0x91, 0x02, // Output (Data,Var,Abs) 74 > 0xc0, // End Collection 76 > > So with the current implementation of hid_validate_report(), it works, > but if another Buzz controller show up at some point with extras > fields in this output report... we will be screwed. So please, amend > hid_validate_report(), or specifically test here that the LED output > report is 7 bytes. hid_validate_report() checks for "at least" 7 in this call, so it should be fine, unless I've misunderstood something. -Kees > > Cheers, > Benjamin > >> + return -ENODEV; >> + >> buzz = kzalloc(sizeof(*buzz), GFP_KERNEL); >> if (!buzz) { >> hid_err(hdev, "Insufficient memory, cannot allocate driver data\n"); >> >> -- >> Jiri Kosina >> SUSE Labs >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-input" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Aug 29, 2013 at 4:40 PM, Kees Cook <keescook@chromium.org> wrote: > On Thu, Aug 29, 2013 at 2:48 AM, Benjamin Tissoires > <benjamin.tissoires@gmail.com> wrote: >> On Wed, Aug 28, 2013 at 10:30 PM, Jiri Kosina <jkosina@suse.cz> wrote: >>> From: Kees Cook <keescook@chromium.org> >>> >>> This driver must validate the availability of the HID output report and >>> its size before it can write LED states via buzz_set_leds(). This stops >>> a heap overflow that is possible if a device provides a malicious HID >>> output report: >>> >>> [ 108.171280] usb 1-1: New USB device found, idVendor=054c, idProduct=0002 >>> ... >>> [ 117.507877] BUG kmalloc-192 (Not tainted): Redzone overwritten >>> >>> CVE-2013-2890 >>> >>> Signed-off-by: Kees Cook <keescook@chromium.org> >>> Cc: stable@kernel.org >>> --- >>> drivers/hid/hid-sony.c | 4 ++++ >>> 1 file changed, 4 insertions(+) >>> >>> diff --git a/drivers/hid/hid-sony.c b/drivers/hid/hid-sony.c >>> index 87fbe29..b987926 100644 >>> --- a/drivers/hid/hid-sony.c >>> +++ b/drivers/hid/hid-sony.c >>> @@ -537,6 +537,10 @@ static int buzz_init(struct hid_device *hdev) >>> drv_data = hid_get_drvdata(hdev); >>> BUG_ON(!(drv_data->quirks & BUZZ_CONTROLLER)); >>> >>> + /* Validate expected report characteristics. */ >>> + if (!hid_validate_report(hdev, HID_OUTPUT_REPORT, 0, 1, 7)) >> >> I don't have access to the device anymore, but I still kept the report >> descriptors (this is the interesting part): >> >> 0xa1, 0x02, // Collection (Logical) 60 >> 0x75, 0x08, // Report Size (8) 62 >> 0x95, 0x07, // Report Count (7) 64 >> 0x46, 0xff, 0x00, // Physical Maximum (255) 66 >> 0x26, 0xff, 0x00, // Logical Maximum (255) 69 >> 0x09, 0x02, // Usage (Vendor Usage 2) 72 >> 0x91, 0x02, // Output (Data,Var,Abs) 74 >> 0xc0, // End Collection 76 >> >> So with the current implementation of hid_validate_report(), it works, >> but if another Buzz controller show up at some point with extras >> fields in this output report... we will be screwed. So please, amend >> hid_validate_report(), or specifically test here that the LED output >> report is 7 bytes. > > hid_validate_report() checks for "at least" 7 in this call, so it > should be fine, unless I've misunderstood something. > Sure, it' s fine with the current implementation of hid_validate_report(). However, as I mentioned in patch 2/14, I am complaining about the implementation of hid_validate_report(). In this case, if a new Buzz controller pops out with an extra usage (Vendor 3 for instance), mapped to another LED, and that the report count is for this usage < 7, the test invalidate the report. for instance, let's imagine they pop up a new version: 0xa1, 0x02, // Collection (Logical) 60 0x75, 0x08, // Report Size (8) 62 0x95, 0x07, // **Report Count (7)** 64 0x46, 0xff, 0x00, // Physical Maximum (255) 66 0x26, 0xff, 0x00, // Logical Maximum (255) 69 0x09, 0x02, // Usage (Vendor Usage 2) 72 0x91, 0x02, // Output (Data,Var,Abs) 74 0x75, 0x08, // Report Size (8) 62 0x95, 0x04, // **Report Count (4)** 64 0x46, 0xff, 0x00, // Physical Maximum (255) 66 0x26, 0xff, 0x00, // Logical Maximum (255) 69 0x09, 0x03, // Usage (Vendor Usage 3) 72 0x91, 0x02, // Output (Data,Var,Abs) 74 0xc0, // End Collection 76 Ok, it's a lot of "if", but still this output report is valid, and the test will fail. And if we call hid_validate_report(hdev, HID_OUTPUT_REPORT, 0, 1, 4), the validation will fail, but the heap overflow will appear again. Does it makes more sense? Cheers, Benjamin >>> + return -ENODEV; >>> + >>> buzz = kzalloc(sizeof(*buzz), GFP_KERNEL); >>> if (!buzz) { >>> hid_err(hdev, "Insufficient memory, cannot allocate driver data\n"); >>> >>> -- >>> Jiri Kosina >>> SUSE Labs >>> -- >>> To unsubscribe from this list: send the line "unsubscribe linux-input" in >>> the body of a message to majordomo@vger.kernel.org >>> More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > -- > Kees Cook > Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Aug 29, 2013 at 7:50 AM, Benjamin Tissoires <benjamin.tissoires@gmail.com> wrote: > On Thu, Aug 29, 2013 at 4:40 PM, Kees Cook <keescook@chromium.org> wrote: >> On Thu, Aug 29, 2013 at 2:48 AM, Benjamin Tissoires >> <benjamin.tissoires@gmail.com> wrote: >>> On Wed, Aug 28, 2013 at 10:30 PM, Jiri Kosina <jkosina@suse.cz> wrote: >>>> From: Kees Cook <keescook@chromium.org> >>>> >>>> This driver must validate the availability of the HID output report and >>>> its size before it can write LED states via buzz_set_leds(). This stops >>>> a heap overflow that is possible if a device provides a malicious HID >>>> output report: >>>> >>>> [ 108.171280] usb 1-1: New USB device found, idVendor=054c, idProduct=0002 >>>> ... >>>> [ 117.507877] BUG kmalloc-192 (Not tainted): Redzone overwritten >>>> >>>> CVE-2013-2890 >>>> >>>> Signed-off-by: Kees Cook <keescook@chromium.org> >>>> Cc: stable@kernel.org >>>> --- >>>> drivers/hid/hid-sony.c | 4 ++++ >>>> 1 file changed, 4 insertions(+) >>>> >>>> diff --git a/drivers/hid/hid-sony.c b/drivers/hid/hid-sony.c >>>> index 87fbe29..b987926 100644 >>>> --- a/drivers/hid/hid-sony.c >>>> +++ b/drivers/hid/hid-sony.c >>>> @@ -537,6 +537,10 @@ static int buzz_init(struct hid_device *hdev) >>>> drv_data = hid_get_drvdata(hdev); >>>> BUG_ON(!(drv_data->quirks & BUZZ_CONTROLLER)); >>>> >>>> + /* Validate expected report characteristics. */ >>>> + if (!hid_validate_report(hdev, HID_OUTPUT_REPORT, 0, 1, 7)) >>> >>> I don't have access to the device anymore, but I still kept the report >>> descriptors (this is the interesting part): >>> >>> 0xa1, 0x02, // Collection (Logical) 60 >>> 0x75, 0x08, // Report Size (8) 62 >>> 0x95, 0x07, // Report Count (7) 64 >>> 0x46, 0xff, 0x00, // Physical Maximum (255) 66 >>> 0x26, 0xff, 0x00, // Logical Maximum (255) 69 >>> 0x09, 0x02, // Usage (Vendor Usage 2) 72 >>> 0x91, 0x02, // Output (Data,Var,Abs) 74 >>> 0xc0, // End Collection 76 >>> >>> So with the current implementation of hid_validate_report(), it works, >>> but if another Buzz controller show up at some point with extras >>> fields in this output report... we will be screwed. So please, amend >>> hid_validate_report(), or specifically test here that the LED output >>> report is 7 bytes. >> >> hid_validate_report() checks for "at least" 7 in this call, so it >> should be fine, unless I've misunderstood something. >> > > Sure, it' s fine with the current implementation of > hid_validate_report(). However, as I mentioned in patch > 2/14, I am complaining about the implementation of hid_validate_report(). > > In this case, if a new Buzz controller pops out with an extra usage > (Vendor 3 for instance), mapped to another LED, and that the report > count is for this usage < 7, the test invalidate the report. > > for instance, let's imagine they pop up a new version: > > 0xa1, 0x02, // Collection (Logical) 60 > 0x75, 0x08, // Report Size (8) 62 > 0x95, 0x07, // **Report Count (7)** 64 > 0x46, 0xff, 0x00, // Physical Maximum (255) 66 > 0x26, 0xff, 0x00, // Logical Maximum (255) 69 > 0x09, 0x02, // Usage (Vendor Usage 2) 72 > 0x91, 0x02, // Output (Data,Var,Abs) 74 > 0x75, 0x08, // Report Size (8) 62 > 0x95, 0x04, // **Report Count (4)** 64 > 0x46, 0xff, 0x00, // Physical Maximum (255) 66 > 0x26, 0xff, 0x00, // Logical Maximum (255) 69 > 0x09, 0x03, // Usage (Vendor Usage 3) 72 > 0x91, 0x02, // Output (Data,Var,Abs) 74 > 0xc0, // End Collection 76 > > Ok, it's a lot of "if", but still this output report is valid, and the > test will fail. And if we call hid_validate_report(hdev, > HID_OUTPUT_REPORT, 0, 1, 4), the validation will fail, but the heap > overflow will appear again. > > Does it makes more sense? Right, yeah, I understand what you meant here, but I guess my point was, if there's something that uses <7, then the driver needs adjustment too, beyond just the hid_validate_report() call, since it would need to know to operate only on 4 instead of 7. My thinking was, if such a thing is detected, it would need to identify which device it was and fix both the bounds-checking, and the report-value-setting. For example: if (i_am_vendor_3()) { hid_validate_report(hdev, HID_OUTPUT_REPORT, 0, 1, 4); } else { hid_validate_report(hdev, HID_OUTPUT_REPORT, 0, 1, 7); } ... value[0] = 0x00; value[1] = (leds & 1) ? 0xff : 0x00; value[2] = (leds & 2) ? 0xff : 0x00; value[3] = (leds & 4) ? 0xff : 0x00; if (!i_am_vendor_3()) { value[4] = (leds & 8) ? 0xff : 0x00; value[5] = 0x00; value[6] = 0x00; } But actually, the logic would be id or usage based, but still, it seems to me that the hid_validate_report() call must match the actual value array assignments. -Kees > > Cheers, > Benjamin > >>>> + return -ENODEV; >>>> + >>>> buzz = kzalloc(sizeof(*buzz), GFP_KERNEL); >>>> if (!buzz) { >>>> hid_err(hdev, "Insufficient memory, cannot allocate driver data\n"); >>>> >>>> -- >>>> Jiri Kosina >>>> SUSE Labs >>>> -- >>>> To unsubscribe from this list: send the line "unsubscribe linux-input" in >>>> the body of a message to majordomo@vger.kernel.org >>>> More majordomo info at http://vger.kernel.org/majordomo-info.html >> >> >> >> -- >> Kees Cook >> Chrome OS Security
On Thu, Aug 29, 2013 at 9:58 PM, Kees Cook <keescook@chromium.org> wrote: > On Thu, Aug 29, 2013 at 7:50 AM, Benjamin Tissoires > <benjamin.tissoires@gmail.com> wrote: >> On Thu, Aug 29, 2013 at 4:40 PM, Kees Cook <keescook@chromium.org> wrote: >>> On Thu, Aug 29, 2013 at 2:48 AM, Benjamin Tissoires >>> <benjamin.tissoires@gmail.com> wrote: >>>> On Wed, Aug 28, 2013 at 10:30 PM, Jiri Kosina <jkosina@suse.cz> wrote: >>>>> From: Kees Cook <keescook@chromium.org> >>>>> >>>>> This driver must validate the availability of the HID output report and >>>>> its size before it can write LED states via buzz_set_leds(). This stops >>>>> a heap overflow that is possible if a device provides a malicious HID >>>>> output report: >>>>> >>>>> [ 108.171280] usb 1-1: New USB device found, idVendor=054c, idProduct=0002 >>>>> ... >>>>> [ 117.507877] BUG kmalloc-192 (Not tainted): Redzone overwritten >>>>> >>>>> CVE-2013-2890 >>>>> >>>>> Signed-off-by: Kees Cook <keescook@chromium.org> >>>>> Cc: stable@kernel.org >>>>> --- >>>>> drivers/hid/hid-sony.c | 4 ++++ >>>>> 1 file changed, 4 insertions(+) >>>>> >>>>> diff --git a/drivers/hid/hid-sony.c b/drivers/hid/hid-sony.c >>>>> index 87fbe29..b987926 100644 >>>>> --- a/drivers/hid/hid-sony.c >>>>> +++ b/drivers/hid/hid-sony.c >>>>> @@ -537,6 +537,10 @@ static int buzz_init(struct hid_device *hdev) >>>>> drv_data = hid_get_drvdata(hdev); >>>>> BUG_ON(!(drv_data->quirks & BUZZ_CONTROLLER)); >>>>> >>>>> + /* Validate expected report characteristics. */ >>>>> + if (!hid_validate_report(hdev, HID_OUTPUT_REPORT, 0, 1, 7)) >>>> >>>> I don't have access to the device anymore, but I still kept the report >>>> descriptors (this is the interesting part): >>>> >>>> 0xa1, 0x02, // Collection (Logical) 60 >>>> 0x75, 0x08, // Report Size (8) 62 >>>> 0x95, 0x07, // Report Count (7) 64 >>>> 0x46, 0xff, 0x00, // Physical Maximum (255) 66 >>>> 0x26, 0xff, 0x00, // Logical Maximum (255) 69 >>>> 0x09, 0x02, // Usage (Vendor Usage 2) 72 >>>> 0x91, 0x02, // Output (Data,Var,Abs) 74 >>>> 0xc0, // End Collection 76 >>>> >>>> So with the current implementation of hid_validate_report(), it works, >>>> but if another Buzz controller show up at some point with extras >>>> fields in this output report... we will be screwed. So please, amend >>>> hid_validate_report(), or specifically test here that the LED output >>>> report is 7 bytes. >>> >>> hid_validate_report() checks for "at least" 7 in this call, so it >>> should be fine, unless I've misunderstood something. >>> >> >> Sure, it' s fine with the current implementation of >> hid_validate_report(). However, as I mentioned in patch >> 2/14, I am complaining about the implementation of hid_validate_report(). >> >> In this case, if a new Buzz controller pops out with an extra usage >> (Vendor 3 for instance), mapped to another LED, and that the report >> count is for this usage < 7, the test invalidate the report. >> >> for instance, let's imagine they pop up a new version: >> >> 0xa1, 0x02, // Collection (Logical) 60 >> 0x75, 0x08, // Report Size (8) 62 >> 0x95, 0x07, // **Report Count (7)** 64 >> 0x46, 0xff, 0x00, // Physical Maximum (255) 66 >> 0x26, 0xff, 0x00, // Logical Maximum (255) 69 >> 0x09, 0x02, // Usage (Vendor Usage 2) 72 >> 0x91, 0x02, // Output (Data,Var,Abs) 74 >> 0x75, 0x08, // Report Size (8) 62 >> 0x95, 0x04, // **Report Count (4)** 64 >> 0x46, 0xff, 0x00, // Physical Maximum (255) 66 >> 0x26, 0xff, 0x00, // Logical Maximum (255) 69 >> 0x09, 0x03, // Usage (Vendor Usage 3) 72 >> 0x91, 0x02, // Output (Data,Var,Abs) 74 >> 0xc0, // End Collection 76 >> >> Ok, it's a lot of "if", but still this output report is valid, and the >> test will fail. And if we call hid_validate_report(hdev, >> HID_OUTPUT_REPORT, 0, 1, 4), the validation will fail, but the heap >> overflow will appear again. >> >> Does it makes more sense? > > Right, yeah, I understand what you meant here, but I guess my point > was, if there's something that uses <7, then the driver needs > adjustment too, beyond just the hid_validate_report() call, since it > would need to know to operate only on 4 instead of 7. My thinking was, > if such a thing is detected, it would need to identify which device it > was and fix both the bounds-checking, and the report-value-setting. > For example: > > if (i_am_vendor_3()) { > hid_validate_report(hdev, HID_OUTPUT_REPORT, 0, 1, 4); > } else { > hid_validate_report(hdev, HID_OUTPUT_REPORT, 0, 1, 7); > } > hmm... not really. In my case, I supposed the device presented both vendor collections, one after the other. So the test could be: hid_validate_report(hdev, HID_OUTPUT_REPORT, 0, 1, 7); if (I_contain_vendor_3()) hid_validate_report(hdev, HID_OUTPUT_REPORT, 0, 2, 4); But this will not work if the small report is in front of the large one. I can propose another implementation of hid_validate_report() which will be covering this case: instead of checking a range of fields, just check the specific field index used later: +struct hid_report *hid_validate_report(struct hid_device *hid, + unsigned int type, unsigned int id, + unsigned int field_index, + unsigned int report_counts) +{ + struct hid_report *report; + + if (type > HID_FEATURE_REPORT) { + hid_err(hid, "invalid HID report %u\n", type); + return NULL; + } + + report = hid->report_enum[type].report_id_hash[id]; + if (!report) { + hid_err(hid, "missing %s %u\n", hid_report_names[type], id); + return NULL; + } + if (report->maxfield <= field_index) { + hid_err(hid, "not enough fields in %s %u\n", + hid_report_names[type], id); + return NULL; + } + + if (report->field[field_index]->report_count < report_counts) { + hid_err(hid, "not enough values in %s %u field #%d\n", + hid_report_names[type], id, field_index); + return NULL; + } + return report; +} +EXPORT_SYMBOL_GPL(hid_validate_report); Only hid-zpff and hid-lenovo-tpkbd are checking for more than one report, and we can afford a for loop on the field indexes for them. Cheers, Benjamin > ... > > value[0] = 0x00; > value[1] = (leds & 1) ? 0xff : 0x00; > value[2] = (leds & 2) ? 0xff : 0x00; > value[3] = (leds & 4) ? 0xff : 0x00; > if (!i_am_vendor_3()) { > value[4] = (leds & 8) ? 0xff : 0x00; > value[5] = 0x00; > value[6] = 0x00; > } > > But actually, the logic would be id or usage based, but still, it > seems to me that the hid_validate_report() call must match the actual > value array assignments. > > -Kees > >> >> Cheers, >> Benjamin >> >>>>> + return -ENODEV; >>>>> + >>>>> buzz = kzalloc(sizeof(*buzz), GFP_KERNEL); >>>>> if (!buzz) { >>>>> hid_err(hdev, "Insufficient memory, cannot allocate driver data\n"); >>>>> >>>>> -- >>>>> Jiri Kosina >>>>> SUSE Labs >>>>> -- >>>>> To unsubscribe from this list: send the line "unsubscribe linux-input" in >>>>> the body of a message to majordomo@vger.kernel.org >>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>> >>> >>> >>> -- >>> Kees Cook >>> Chrome OS Security > > > > -- > Kees Cook > Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/hid/hid-sony.c b/drivers/hid/hid-sony.c index 87fbe29..b987926 100644 --- a/drivers/hid/hid-sony.c +++ b/drivers/hid/hid-sony.c @@ -537,6 +537,10 @@ static int buzz_init(struct hid_device *hdev) drv_data = hid_get_drvdata(hdev); BUG_ON(!(drv_data->quirks & BUZZ_CONTROLLER)); + /* Validate expected report characteristics. */ + if (!hid_validate_report(hdev, HID_OUTPUT_REPORT, 0, 1, 7)) + return -ENODEV; + buzz = kzalloc(sizeof(*buzz), GFP_KERNEL); if (!buzz) { hid_err(hdev, "Insufficient memory, cannot allocate driver data\n");