On Thu, Aug 29, 2013 at 11:36 AM, Jiri Kosina <jkosina@xxxxxxx> wrote: > On Thu, 29 Aug 2013, Benjamin Tissoires wrote: > >> >> The "Report ID" field of a HID report is used to build indexes of >> >> reports. The kernel's index of these is limited to 256 entries, so any >> >> malicious device that sets a Report ID greater than 255 will trigger >> >> memory corruption on the host: >> >> >> >> [ 1347.156239] BUG: unable to handle kernel paging request at ffff88094958a878 >> >> [ 1347.156261] IP: [<ffffffff813e4da0>] hid_register_report+0x2a/0x8b >> >> >> >> CVE-2013-2888 >> >> >> >> Signed-off-by: Kees Cook <keescook@xxxxxxxxxxxx> >> >> Cc: stable@xxxxxxxxxx >> > >> > Applied this one to hid.git#for-3.11/CVE-2013-2888 >> >> Well, I am a little bit lost here. I know the patch will not break any >> existing things, but still, I really can not understand how this can >> happen: >> >> - Report IDs are specifically specified to be 1-byte fields. That >> means that the max they can have is 0xFF, which is 255 :-/ > > Hmm, with a specially crafted device, you can end up with item->size > 1 > coming out from fetch_item() for report ID, no? Then the problem is in the parser, and if (item->size > 1) for HID_GLOBAL_ITEM_TAG_REPORT_ID, we should directly bail out and reject the device instead of continuing... which is exactly Kees' patch :) Sorry for the noise :) Cheers, Benjamin -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
