Hi Alan,
Here is a revised patch for yesterday's use-after-free bug report. I
moved the hdev assignment and reference inside the hub_event_lock, then
returned the ref on the way out of hub_events.
Ordering is now symmetric:
kref_get(&hub->kref)
usb_get_dev(hdev)
usb_lock_device(hdev)
...
usb_unlock_device(hdev)
usb_put_dev(hdev)
kref_put(&hub->kref, hub_release)
No reports from slub_debug during lastnight's tests.
-->8-- -->8--
>From 5f169da5fbdb6374dc23e8202a7a06fd27196a07 Mon Sep 17 00:00:00 2001
From: Joe Lawrence <joe.lawre...@stratus.com>
Date: Tue, 9 Sep 2014 17:24:41 -0400
Subject: [PATCH] usb: hub: take hub->hdev reference when processing from
eventlist
During surprise device hotplug removal tests, it was observed that
hub_events may try to call usb_lock_device on a device that has already
been freed. Protect the usb_device by taking out a reference (under the
hub_event_lock) when hub_events pulls it off the list, returning the
reference after hub_events is finished using it.
Signed-off-by: Joe Lawrence <joe.lawre...@stratus.com>
Suggested-by: David Bulkow <david.bul...@stratus.com> for using kref
Suggested-by: Alan Stern <st...@rowland.harvard.edu> for placement
---
drivers/usb/core/hub.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 46f5161..d481c99 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -5024,9 +5024,10 @@ static void hub_events(void)
hub = list_entry(tmp, struct usb_hub, event_list);
kref_get(&hub->kref);
+ hdev = hub->hdev;
+ usb_get_dev(hdev);
spin_unlock_irq(&hub_event_lock);
- hdev = hub->hdev;
hub_dev = hub->intfdev;
intf = to_usb_interface(hub_dev);
dev_dbg(hub_dev, "state %d ports %d chg %04x evt %04x\n",
@@ -5139,6 +5140,7 @@ static void hub_events(void)
usb_autopm_put_interface(intf);
loop_disconnected:
usb_unlock_device(hdev);
+ usb_put_dev(hdev);
kref_put(&hub->kref, hub_release);
} /* end while (1) */
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
