usb: wusbcore: don't mark WA_SEG_DTI_PENDING segs as done in urb_dequeue

Data for transfer segments in the WA_SEG_DTI_PENDING state is actively
being read by the driver.  Let the buffer read callback handle the
transfer cleanup since cleaning it up in wa_urb_dequeue will cause the
read callback to access invalid memory if the transfer is completed.

Signed-off-by: Thomas Pugliese <thomas.pugliese@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

diff --git a/drivers/usb/wusbcore/wa-xfer.c b/drivers/usb/wusbcore/wa-xfer.c
index 6e0d377d437c8efe2ac975d8a76248e360eb689d..cf7c95ceebe06e0ceaa6bd733d48de1731724ece 100644 (file)
--- a/drivers/usb/wusbcore/wa-xfer.c
+++ b/drivers/usb/wusbcore/wa-xfer.c
@@ -2005,6 +2005,16 @@ int wa_urb_dequeue(struct wahc *wa, struct urb *urb, int status)
                case WA_SEG_DONE:
                case WA_SEG_ERROR:
                case WA_SEG_ABORTED:
+                       break;
+                       /*
+                        * The buf_in data for a segment in the
+                        * WA_SEG_DTI_PENDING state is actively being read.
+                        * Let wa_buf_in_cb handle it since it will be called
+                        * and will increment xfer->segs_done.  Cleaning up
+                        * here could cause wa_buf_in_cb to access the xfer
+                        * after it has been completed/freed.
+                        */
+               case WA_SEG_DTI_PENDING:
                        break;
                        /*
                         * In the states below, the HWA device already knows
@@ -2015,7 +2025,6 @@ int wa_urb_dequeue(struct wahc *wa, struct urb *urb, int status)
                         */
                case WA_SEG_SUBMITTED:
                case WA_SEG_PENDING:
-               case WA_SEG_DTI_PENDING:
                        /*
                         * Check if the abort was successfully sent.  This could
                         * be false if the HWA has been removed but we haven't