On Thu, Aug 29, 2013 at 4:40 PM, Kees Cook [off-list ref] wrote:

On Thu, Aug 29, 2013 at 2:48 AM, Benjamin Tissoires
[off-list ref] wrote:

quoted

On Wed, Aug 28, 2013 at 10:30 PM, Jiri Kosina [off-list ref] wrote:

quoted

From: Kees Cook <redacted>

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 <redacted>
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

quoted

quoted

+               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