kernel.git/drivers/hid/hid-logitech-dj.c, branch linux-3.4.y

HID: logitech-dj: prevent false errors to be shown

2014-09-25T03:49:14Z

commit 5abfe85c1d4694d5d4bbd13ecc166262b937adf0 upstream. Commit "HID: logitech: perform bounds checking on device_id early enough" unfortunately leaks some errors to dmesg which are not real ones: - if the report is not a DJ one, then there is not point in checking the device_id - the receiver (index 0) can also receive some notifications which can be safely ignored given the current implementation Move out the test regarding the report_id and also discards printing errors when the receiver got notified. Fixes: ad3e14d7c5268c2e24477c6ef54bbdf88add5d36 Reported-and-tested-by: Markus Trippelsdorf Signed-off-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Zefan Li

HID: logitech: perform bounds checking on device_id early enough

2014-09-25T03:49:10Z

commit ad3e14d7c5268c2e24477c6ef54bbdf88add5d36 upstream. device_index is a char type and the size of paired_dj_deivces is 7 elements, therefore proper bounds checking has to be applied to device_index before it is used. We are currently performing the bounds checking in logi_dj_recv_add_djhid_device(), which is too late, as malicious device could send REPORT_TYPE_NOTIF_DEVICE_UNPAIRED early enough and trigger the problem in one of the report forwarding functions called from logi_dj_raw_event(). Fix this by performing the check at the earliest possible ocasion in logi_dj_raw_event(). Reported-by: Ben Hawkes Reviewed-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Zefan Li

dj: memory scribble in logi_dj

2014-06-07T23:02:15Z

commit 8a55ade76551e3927b4e41ee9e7751875d18bc25 upstream. Allocate a structure not a pointer to it ! Signed-off-by: Alan Cox Signed-off-by: Linus Torvalds Cc: Yijing Wang Cc: Marc Dionne Signed-off-by: Greg Kroah-Hartman

HID: logitech: don't use stack based dj_report structures

2014-06-07T23:02:15Z

commit d8dc3494f77a5cc3b274bae36f7e74e85cf8a407 upstream. On a system with a logitech wireless keyboard/mouse and DMA-API debugging enabled, this warning appears at boot: kernel: WARNING: at lib/dma-debug.c:929 check_for_stack.part.12+0x70/0xa7() kernel: Hardware name: MS-7593 kernel: uhci_hcd 0000:00:1d.1: DMA-API: device driver maps memory fromstack [addr=ffff8801b0079c29] Make logi_dj_recv_query_paired_devices and logi_dj_recv_switch_to_dj_mode use a structure allocated with kzalloc rather than a stack based one. Signed-off-by: Marc Dionne Signed-off-by: Jiri Kosina Signed-off-by: Ben Hutchings Cc: Yijing Wang Signed-off-by: Greg Kroah-Hartman

HID: logitech-dj: validate output report details

2013-10-01T16:10:51Z

commit 297502abb32e225fb23801fcdb0e4f6f8e17099a upstream. A HID device could send a malicious output report that would cause the logitech-dj HID driver to leak kernel memory contents to the device, or trigger a NULL dereference during initialization: [ 304.424553] usb 1-1: New USB device found, idVendor=046d, idProduct=c52b ... [ 304.780467] BUG: unable to handle kernel NULL pointer dereference at 0000000000000028 [ 304.781409] IP: [] logi_dj_recv_send_report.isra.11+0x1a/0x90 CVE-2013-2895 Signed-off-by: Kees Cook Signed-off-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman

HID: logitech-dj: do not directly call hid_output_raw_report() during probe

2013-03-14T18:29:50Z

commit dcd9006b1b053c7b1cebe81333261d4fd492ffeb upstream. hid_output_raw_report() makes a direct call to usb_control_msg(). However, some USB3 boards have shown that the usb device is not ready during the .probe(). This blocks the entire usb device, and the paired mice, keyboards are not functional. The dmesg output is the following: [ 11.912287] logitech-djreceiver 0003:046D:C52B.0003: hiddev0,hidraw0: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:14.0-2/input2 [ 11.912537] logitech-djreceiver 0003:046D:C52B.0003: logi_dj_probe:logi_dj_recv_query_paired_devices error:-32 [ 11.912636] logitech-djreceiver: probe of 0003:046D:C52B.0003 failed with error -32 Relying on the scheduled call to usbhid_submit_report() fixes the problem. related bugs: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1072082 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1039143 https://bugzilla.redhat.com/show_bug.cgi?id=840391 https://bugzilla.kernel.org/show_bug.cgi?id=49781 Reported-and-tested-by: Bob Bowles Signed-off-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman

HID: Fix logitech-dj: missing Unifying device issue

2012-10-02T17:30:06Z

commit 596264082f10dd4a567c43d4526b2f54ac5520bc upstream. This patch fixes an issue introduced after commit 4ea5454203d991ec ("HID: Fix race condition between driver core and ll-driver"). After that commit, hid-core discards any incoming packet that arrives while hid driver's probe function is being executed. This broke the enumeration process of hid-logitech-dj, that must receive control packets in-band with the mouse and keyboard packets. Discarding mouse or keyboard data at the very begining is usually fine, but it is not the case for control packets. This patch forces a re-enumeration of the paired devices when a packet arrives that comes from an unknown device. Based on a patch originally written by Benjamin Tissoires. Signed-off-by: Nestor Lopez Casado Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman

HID: logitech: read all 32 bits of report type bitfield

2012-06-01T07:18:17Z

commit 44d27f7dfedd9aadc082cda31462f6600f56e4ec upstream. On big-endian systems (e.g., Apple PowerBook), trying to use a logitech wireless mouse with the Logitech Unifying Receiver does not work with v3.2 and later kernels. The device doesn't show up in /dev/input. Older kernels work fine. That is because the new hid-logitech-dj driver claims the device. The device arrival notification appears: 20 00 41 02 00 00 00 00 00 00 00 00 00 00 00 and we read the report_types bitfield (02 00 00 00) to find out what kind of device it is. Unfortunately the driver only reads the first 8 bits and treats that value as a 32-bit little-endian number, so on a powerpc the report type seems to be 0x02000000 and is not recognized. Even on little-endian machines, connecting a media center remote control (report type 00 01 00 00) with this driver loaded would presumably fail for the same reason. Fix both problems by using get_unaligned_le32() to read all four bytes, which is a little clearer anyway. After this change, the wireless mouse works on Hugo's PowerBook again. Based on a patch by Nestor Lopez Casado. Addresses http://bugs.debian.org/671292 Reported-by: Hugo Osvaldo Barrera Inspired-by: Nestor Lopez Casado Signed-off-by: Jonathan Nieder Signed-off-by: Nestor Lopez Casado Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman

HID: logitech: fix mask to enable DJ mode

2012-02-02T09:54:14Z

The user can only experience the bug if she pairs 6 devices to a Unifying receiver. The sixth paired device would not work. The value changed is actually a bitmask that enables reporting from each paired device. As the sixth bit was not set, the sixth device reports are ignored by the receiver and never get to the driver. Signed-off-by: Nestor Lopez Casado drivers/hid/hid-logitech-dj.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Signed-off-by: Jiri Kosina

HID: hid-logitech-dj: fix off by one

2011-09-20T14:09:22Z

There is a bug where a device with index 6 would write out of bounds in the array of paired devices. This patch fixes that problem. Reported-by: Dan Carpenter Reviewed-by: Benjamin Tissoires Reviewed-by: Olivier Gay Signed-off-by: Nestor Lopez Casado Signed-off-by: Jiri Kosina