[PATCH v2] HID: rmi: check that report ids exist in the report_id_hash before accessing their size

It is possible that the hid-rmi driver could get loaded onto a device which does not have the
expected report ids. This should not happen because it would indicate that the hid-rmi driver is
not compatible with that device. However, if it does happen it should return an error from probe
instead of dereferencing a null pointer.

related bug:
https://bugzilla.kernel.org/show_bug.cgi?id=80091

Signed-off-by: Andrew Duggan <redacted>
---
Added hid_err messages as suggested by Benjamin. This fixes the null pointer dereference from
bug 80091 while the next patch addresses the binding issue in hid-core.

 drivers/hid/hid-rmi.c | 28 ++++++++++++++++++++++------
 1 file changed, 22 insertions(+), 6 deletions(-)

diff --git a/drivers/hid/hid-rmi.c b/drivers/hid/hid-rmi.c
index 3221a95..260be7a 100644
--- a/drivers/hid/hid-rmi.c
+++ b/drivers/hid/hid-rmi.c

@@ -848,6 +848,8 @@ static int rmi_probe(struct hid_device *hdev, const struct hid_device_id *id)
 	struct rmi_data *data = NULL;
 	int ret;
 	size_t alloc_size;
+	struct hid_report *input_report;
+	struct hid_report *output_report;
 
 	data = devm_kzalloc(&hdev->dev, sizeof(struct rmi_data), GFP_KERNEL);
 	if (!data)

@@ -866,12 +868,26 @@ static int rmi_probe(struct hid_device *hdev, const struct hid_device_id *id)
 		return ret;
 	}
 
-	data->input_report_size = (hdev->report_enum[HID_INPUT_REPORT]
-		.report_id_hash[RMI_ATTN_REPORT_ID]->size >> 3)
-		+ 1 /* report id */;
-	data->output_report_size = (hdev->report_enum[HID_OUTPUT_REPORT]
-		.report_id_hash[RMI_WRITE_REPORT_ID]->size >> 3)
-		+ 1 /* report id */;
+	input_report = hdev->report_enum[HID_INPUT_REPORT]
+			.report_id_hash[RMI_ATTN_REPORT_ID];
+	if (!input_report) {
+		hid_err(hdev, "device does not have expected input report\n");
+		ret = -ENODEV;
+		return ret;
+	}
+
+	data->input_report_size = (input_report->size >> 3) + 1 /* report id */;
+
+	output_report = hdev->report_enum[HID_OUTPUT_REPORT]
+			.report_id_hash[RMI_WRITE_REPORT_ID];
+	if (!output_report) {
+		hid_err(hdev, "device does not have expected output report\n");
+		ret = -ENODEV;
+		return ret;
+	}
+
+	data->output_report_size = (output_report->size >> 3)
+					+ 1 /* report id */;
 
 	alloc_size = data->output_report_size + data->input_report_size;
 

-- 
1.9.1

On composite HID devices there may be multiple HID devices on separate interfaces, but hid-rmi
should only bind to the mouse interface. One example is the Dell Venue 11 Pro's keyboard dock
which contains a composite USB device with a HID touchpad and HID keyboard on separate intefaces.
Since the USB Vendor ID is Synaptic's, hid-core is currently trying to bind hid-rmi to all\of
the HID devices. This patch ensures that hid-rmi only binds to the mouse interface.

related bug:
https://bugzilla.kernel.org/show_bug.cgi?id=80091

Signed-off-by: Andrew Duggan <redacted>
---
 drivers/hid/hid-core.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 8ed66fd..f10e768 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c

@@ -783,7 +783,9 @@ static int hid_scan_report(struct hid_device *hid)
 	* Vendor specific handlings
 	*/
 	if ((hid->vendor == USB_VENDOR_ID_SYNAPTICS) &&
-	    (hid->group == HID_GROUP_GENERIC))
+	    (hid->group == HID_GROUP_GENERIC) &&
+	    /* only bind to the mouse interface of composite USB devices */
+	    (hid->bus != BUS_USB || hid->type == HID_TYPE_USBMOUSE))
 		/* hid-rmi should take care of them, not hid-generic */
 		hid->group = HID_GROUP_RMI;
 

-- 
1.9.1

On Jul 17 2014 or thereabouts, Andrew Duggan wrote:

On composite HID devices there may be multiple HID devices on separate interfaces, but hid-rmi
should only bind to the mouse interface. One example is the Dell Venue 11 Pro's keyboard dock
which contains a composite USB device with a HID touchpad and HID keyboard on separate intefaces.
Since the USB Vendor ID is Synaptic's, hid-core is currently trying to bind hid-rmi to all\of
the HID devices. This patch ensures that hid-rmi only binds to the mouse interface.

related bug:
https://bugzilla.kernel.org/show_bug.cgi?id=80091

Signed-off-by: Andrew Duggan <redacted>
---

As mentioned in a private mail, Andrew told me that for now, each
touchpad using hid-rmi he has seen are using the boot mouse protocol, so
this patch will give us some space and will not break existing current
setups.

Reviewed-by: Benjamin Tissoires <redacted>

Cheers,
Benjamin

On Thu, 17 Jul 2014, Andrew Duggan wrote:

On composite HID devices there may be multiple HID devices on separate interfaces, but hid-rmi
should only bind to the mouse interface. One example is the Dell Venue 11 Pro's keyboard dock
which contains a composite USB device with a HID touchpad and HID keyboard on separate intefaces.
Since the USB Vendor ID is Synaptic's, hid-core is currently trying to bind hid-rmi to all\of
the HID devices. This patch ensures that hid-rmi only binds to the mouse interface.

related bug:
https://bugzilla.kernel.org/show_bug.cgi?id=80091

Signed-off-by: Andrew Duggan <redacted>

Applied, thanks.

-- 
Jiri Kosina
SUSE Labs

On Jul 17 2014 or thereabouts, Andrew Duggan wrote:

It is possible that the hid-rmi driver could get loaded onto a device which does not have the
expected report ids. This should not happen because it would indicate that the hid-rmi driver is
not compatible with that device. However, if it does happen it should return an error from probe
instead of dereferencing a null pointer.

related bug:
https://bugzilla.kernel.org/show_bug.cgi?id=80091

Signed-off-by: Andrew Duggan <redacted>
---
Added hid_err messages as suggested by Benjamin. This fixes the null pointer dereference from
bug 80091 while the next patch addresses the binding issue in hid-core.

Reviewed-by: Benjamin Tissoires <redacted>

Cheers,
Benjamin

On Thu, 17 Jul 2014, Andrew Duggan wrote:

It is possible that the hid-rmi driver could get loaded onto a device which does not have the
expected report ids. This should not happen because it would indicate that the hid-rmi driver is
not compatible with that device. However, if it does happen it should return an error from probe
instead of dereferencing a null pointer.

related bug:
https://bugzilla.kernel.org/show_bug.cgi?id=80091

Signed-off-by: Andrew Duggan <redacted>

Applied, thanks.

-- 
Jiri Kosina
SUSE Labs