linux-toradex.git/drivers/hid/hid-logitech-dj.c, branch v4.11

HID: logitech-dj: check report length

2014-12-17T07:50:12+00:00

Malicious USB devices can send bogus reports smaller than the expected
buffer size. Ensure that the length is valid to avoid reading out of
bounds.

Signed-off-by: Peter Wu 
Reviewed-by: Benjamin Tissoires 
Signed-off-by: Jiri Kosina

HID: logitech-dj: enable notifications on connect/disconnect

2014-10-29T09:51:40+00:00

The receiver can send HID++ notifications to the DJ devices when the
physical devices are connected/disconnected.
Enable this feature by default.

This command uses a HID++ command instead of a DJ one, so use a direct
call to usbhid instead of using logi_dj_recv_send_report()

Signed-off-by: Benjamin Tissoires 
Tested-by: Andrew de los Reyes 
Signed-off-by: Jiri Kosina

HID: logitech: allow the DJ device to request the unifying name

2014-10-29T09:51:40+00:00

The names of the DJ devices are stored in the receiver. These names
can be retrieved through a HID++ command. However, the protocol says
that you have to ask the receiver for that, not the device iteself.

Introduce a special case in the DJ handling where a device can request
its unifying name, and when such a name is given, forward it also to
the corresponding device.

On the HID++ side, the receiver talks only HID++ 1.0, so we need to
implement this part of the protocol in the module.

Signed-off-by: Benjamin Tissoires 
Tested-by: Andrew de los Reyes 
Signed-off-by: Jiri Kosina

HID: logitech-dj: allow transfer of HID++ reports from/to the correct dj device

2014-10-29T09:51:40+00:00

HID++ is a Logitech-specific protocol for communicating with HID
devices. DJ devices implement HID++, and so we can add the HID++
collection in the report descriptor and forward the incoming
reports from the receiver to the appropriate DJ device.

The same can be done in the other way, if someone calls a
.raw_request(), we can forward it to the correct dj device
by overriding the device_index in the HID++ report.

Signed-off-by: Benjamin Tisssoires 
Tested-by: Andrew de los Reyes 
Signed-off-by: Jiri Kosina

HID: logitech: move dj devices to the HID++ module

2014-10-29T09:51:39+00:00

Devices connected through the Logitech Wireless Receiver are HID++ devices.
We can handle them here to benefit from this new module and activate
enhaced support of the various wireless touchpad or mice with touch
sensors on them.

Signed-off-by: Benjamin Tissoires 
Tested-by: Andrew de los Reyes 
Signed-off-by: Jiri Kosina

HID: logitech-dj: merge header file into the source

2014-10-29T09:51:39+00:00

There is no point in keeping the header in a separate file, nobody
but hid-logitech-dj should have access to its content.

Signed-off-by: Benjamin Tissoires 
Tested-by: Andrew de los Reyes 
Signed-off-by: Jiri Kosina

HID: logitech-dj: rely on hid groups to separate receivers from dj devices

2014-10-29T09:51:38+00:00

Several benefits here:
- we can drop the macro is_dj_device: I never been really conviced by
  this macro as we could fall into a null pointer anytime. Anyway time
  showed that this never happened.
- we can simplify the hid driver logitech-djdevice, and make it aware
  of any new receiver VID/PID.
- we can use the Wireless PID of the DJ device as the product id of the
  hid device, this way the sysfs will differentiate between different
  DJ devices.

Signed-off-by: Benjamin Tisssoires 
Tested-by: Andrew de los Reyes 
Signed-off-by: Jiri Kosina

HID: logitech-dj: break out testing of validity of dj_device

2014-08-27T21:04:21+00:00

We can do once the test of the validity of the dj_device, which removes
some duplicated code in various functions.

Signed-off-by: Benjamin Tissoires 
Signed-off-by: Jiri Kosina

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

2014-08-25T07:59:51+00:00

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

Cc: stable@vger.kernel.org
Reported-and-tested-by: Markus Trippelsdorf 
Signed-off-by: Benjamin Tissoires 
Signed-off-by: Jiri Kosina

HID: logitech: perform bounds checking on device_id early enough

2014-08-21T15:43:06+00:00

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().

Cc: stable@vger.kernel.org
Reported-by: Ben Hawkes 
Reviewed-by: Benjamin Tissoires 
Signed-off-by: Jiri Kosina