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? -- Jiri Kosina SUSE Labs -- 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
