This patch (as1592) fixes an obscure problem in the usbhid driver.
Under some circumstances, a control or interrupt-OUT URB can be
submitted twice. This will happen if the first submission fails; the
queue pointers aren't updated, so the next time the queue is restarted
the same URB will be submitted again.
The problem is that raw_report gets deallocated during the first
submission. The second submission will then dereference and try to
free an already-freed region of memory. The patch fixes the problem
by setting raw_report to NULL when it is deallocated and checking for
NULL before dereferencing it.
Signed-off-by: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>
CC: Oliver Neukum <oliver@xxxxxxxxxx>
---
drivers/hid/usbhid/hid-core.c | 16 +++++++++++-----
1 file changed, 11 insertions(+), 5 deletions(-)
Index: usb-3.5/drivers/hid/usbhid/hid-core.c
===================================================================
--- usb-3.5.orig/drivers/hid/usbhid/hid-core.c
+++ usb-3.5/drivers/hid/usbhid/hid-core.c
@@ -331,9 +331,12 @@ static int hid_submit_out(struct hid_dev
usbhid->urbout->transfer_buffer_length = ((report->size - 1) >> 3) +
1 + (report->id > 0);
usbhid->urbout->dev = hid_to_usb_dev(hid);
- memcpy(usbhid->outbuf, raw_report,
- usbhid->urbout->transfer_buffer_length);
- kfree(raw_report);
+ if (raw_report) {
+ memcpy(usbhid->outbuf, raw_report,
+ usbhid->urbout->transfer_buffer_length);
+ kfree(raw_report);
+ usbhid->out[usbhid->outtail].raw_report = NULL;
+ }
dbg_hid("submitting out urb\n");
@@ -362,8 +365,11 @@ static int hid_submit_ctrl(struct hid_de
if (dir == USB_DIR_OUT) {
usbhid->urbctrl->pipe = usb_sndctrlpipe(hid_to_usb_dev(hid), 0);
usbhid->urbctrl->transfer_buffer_length = len;
- memcpy(usbhid->ctrlbuf, raw_report, len);
- kfree(raw_report);
+ if (raw_report) {
+ memcpy(usbhid->ctrlbuf, raw_report, len);
+ kfree(raw_report);
+ usbhid->ctrl[usbhid->ctrltail].raw_report = NULL;
+ }
} else {
int maxpacket, padlen;
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
