linux.git/drivers/hid/uhid.c, branch v3.13

HID: uhid: fix leak for 64/32 UHID_CREATE

2013-11-27T09:53:49+00:00

UHID allows short writes so user-space can omit unused fields. We
automatically set them to 0 in the kernel. However, the 64/32 bit
compat-handler didn't do that in the UHID_CREATE fallback. This will
reveal random kernel heap data (of random size, even) to user-space.

Fixes: befde0226a59 ('HID: uhid: make creating devices work on 64/32 systems')

Reported-by: Ben Hutchings 
Signed-off-by: David Herrmann 
Cc: stable@vger.kernel.org
Signed-off-by: Jiri Kosina

HID: uhid: allocate static minor

2013-09-26T09:03:29+00:00

udev has this nice feature of creating "dead" /dev/ device-nodes if
it finds a devnode: modalias. Once the node is accessed, the kernel
automatically loads the module that provides the node. However, this
requires udev to know the major:minor code to use for the node. This
feature was introduced by:

  commit 578454ff7eab61d13a26b568f99a89a2c9edc881
  Author: Kay Sievers 
  Date:   Thu May 20 18:07:20 2010 +0200

      driver core: add devname module aliases to allow module on-demand auto-loading

However, uhid uses dynamic minor numbers so this doesn't actually work. We
need to load uhid to know which minor it's going to use.

Hence, allocate a static minor (just like uinput does) and we're good
to go.

Reported-by: Tom Gundersen 
Signed-off-by: David Herrmann 
Signed-off-by: Jiri Kosina

Merge branches 'for-3.12/devm', 'for-3.12/i2c-hid', 'for-3.12/i2c-hid-dt', 'for-3.12/logitech', 'for-3.12/multitouch-win8', 'for-3.12/trasnport-driver-cleanup', 'for-3.12/uhid', 'for-3.12/upstream' and 'for-3.12/wiimote' into for-linus

2013-09-06T09:58:37+00:00

HID: uhid: add devname module alias

2013-09-02T11:28:07+00:00

For simple device node creation, add the devname module alias.

Signed-off-by: Marcel Holtmann 
Reviewed-by: David Herrmann 
Signed-off-by: Jiri Kosina

HID: uhid: use generic hidinput_input_event()

2013-07-31T08:33:05+00:00

HID core provides the same functionality and can convert the input event
to a raw output report. We can thus drop UHID_OUTPUT_EV and rely on the
mandatory UHID_OUTPUT.

User-space wasn't able to do anything with UHID_OUTPUT_EV, anyway. They
don't have access to the report fields.

Signed-off-by: David Herrmann 
Acked-by: Benjamin Tissoires 
Signed-off-by: Jiri Kosina

HID: uhid: make creating devices work on 64/32 systems

2013-02-18T10:28:16+00:00

Unfortunately UHID interface, as it was introduced, is broken with 32 bit
userspace running on 64 bit kernels as it uses a pointer in its userspace
facing API.

Fix it by checking if we are executing compat task and munge the request
appropriately.

Reported-by: Kirill A. Shutemov 
Acked-by: Kirill A. Shutemov 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Jiri Kosina

HID: uhid: Fix sending events with invalid data

2012-07-20T07:53:45+00:00

This was detected because events with invalid types were arriving
to userspace.

The code before this patch would only work for the first event in the
queue (when uhid->tail is 0).

Signed-off-by: Vinicius Costa Gomes 
Reviewed-by: David Herrmann 
Signed-off-by: Jiri Kosina

HID: uhid: silence gcc warning

2012-06-18T15:08:30+00:00

gcc is giving me:

drivers/hid/uhid.c: In function ‘uhid_hid_get_raw’:
drivers/hid/uhid.c:157: warning: ‘len’ may be used uninitialized in this function

which is clearly bogus, as

- when used as memcpy() argument, it's initialized properly
- the code is structured in a way that either 'ret' or 'len'
  is always initialized, so the return statement always has
  an initialized value.

Signed-off-by: Jiri Kosina

HID: uhid: implement feature requests

2012-06-18T11:42:03+00:00

HID standard allows sending a feature request to the device which is
answered by an HID report. uhid implements this by sending a UHID_FEATURE
event to user-space which then must answer with UHID_FEATURE_ANSWER. If it
doesn't do this in a timely manner, the request is discarded silently.

We serialize the feature requests, that is, there is always only a single
active feature-request sent to user-space, other requests have to wait.
HIDP and USB-HID do it the same way.

Because we discard feature-requests silently, we must make sure to match
a response to the corresponding request. We use sequence-IDs for this so
user-space must copy the ID from the request into the answer.
Feature-answers are ignored if they do not contain the same ID as the
currently pending feature request.

Internally, we must make sure that feature-requests are synchronized with
UHID_DESTROY and close() events. We must not dead-lock when closing the
HID device, either, so we have to use separate locks.

Signed-off-by: David Herrmann 
Signed-off-by: Jiri Kosina

HID: uhid: forward raw output reports to user-space

2012-06-18T11:42:02+00:00

Some drivers that use non-standard HID features require raw output reports
sent to the device. We now forward these requests directly to user-space
so the transport-level driver can correctly send it to the device or
handle it correspondingly.

There is no way to signal back whether the transmission was successful,
moreover, there might be lots of messages coming out from the driver
flushing the output-queue. However, there is currently no driver that
causes this so we are safe. If some drivers need to transmit lots of data
this way, we need a method to synchronize this and can implement another
UHID_OUTPUT_SYNC event.

Signed-off-by: David Herrmann 
Signed-off-by: Jiri Kosina