This is a note to let you know that I've just added the patch titled

    usbnet: don't clear urb->dev in tx_complete

to the 3.3-stable tree which can be found at:
    
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     usbnet-don-t-clear-urb-dev-in-tx_complete.patch
and it can be found in the queue-3.3 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <[email protected]> know about it.


>From 5d5440a835710d09f0ef18da5000541ec98b537a Mon Sep 17 00:00:00 2001
From: "[email protected]" <[email protected]>
Date: Thu, 22 Mar 2012 03:22:38 +0000
Subject: usbnet: don't clear urb->dev in tx_complete

From: "[email protected]" <[email protected]>

commit 5d5440a835710d09f0ef18da5000541ec98b537a upstream.

URB unlinking is always racing with its completion and tx_complete
may be called before or during running usb_unlink_urb, so tx_complete
must not clear urb->dev since it will be used in unlink path,
otherwise invalid memory accesses or usb device leak may be caused
inside usb_unlink_urb.

Cc: Alan Stern <[email protected]>
Cc: Oliver Neukum <[email protected]>
Signed-off-by: Ming Lei <[email protected]>
Acked-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
 drivers/net/usb/usbnet.c |    1 -
 1 file changed, 1 deletion(-)

--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -1037,7 +1037,6 @@ static void tx_complete (struct urb *urb
        }
 
        usb_autopm_put_interface_async(dev->intf);
-       urb->dev = NULL;
        entry->state = tx_done;
        defer_bh(dev, skb, &dev->txq);
 }


Patches currently in stable-queue which might be from [email protected] are

queue-3.3/usbnet-increase-urb-reference-count-before-usb_unlink_urb.patch
queue-3.3/usbnet-don-t-clear-urb-dev-in-tx_complete.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to