On 27/07/20 12:21, Greg KH wrote:
On Mon, Jul 27, 2020 at 10:22:25AM +0300,eli.billauer@xxxxxxxxx wrote:
From: Eli Billauer<eli.billauer@xxxxxxxxx>
usb_kill_anchored_urbs() is commonly used to cancel all URBs on an
anchor just before releasing resources which the URBs rely on. By doing
so, users of this function rely on that no completer callbacks will take
place from any URB on the anchor after it returns.
However if this function is called in parallel with __usb_hcd_giveback_urb
processing a URB on the anchor, the latter may call the completer
callback after usb_kill_anchored_urbs() returns. This can lead to a
kernel panic due to use after release of memory in interrupt context.
The race condition is that __usb_hcd_giveback_urb() first unanchors the URB
and then makes the completer callback. Such URB is hence invisible to
usb_kill_anchored_urbs(), allowing it to return before the completer has
been called, since the anchor's urb_list is empty.
This patch adds a call to usb_wait_anchor_empty_timeout() prior to
returning. This function waits until urb_list is empty (it should
already be), but more importantly, until @suspend_wakeups is zero.
The latter condition resolves the race condition, since @suspend_wakeups
is incremented by __usb_hcd_giveback_urb() before unanchoring a URB and
decremented after completing it. @suspend_wakeups is hence an upper limit
of the number of unanchored but uncompleted URBs. By waiting for it to be
zero, the race condition is eliminated, in the same way that another
problem was solved for the same race condition in commit 6ec4147e7bdb
("usb-anchor: Delay usb_wait_anchor_empty_timeout wake up till completion
is done").
An arbitrary timeout of 1000 ms should cover any sane completer
callback. The wait condition may also fail if the anchor is populated
while usb_kill_anchored_urbs() is called. Both timeout scenarios are
alarmingly weird, hence a WARN() is issued.
Signed-off-by: Eli Billauer<eli.billauer@xxxxxxxxx>
---
drivers/usb/core/urb.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/core/urb.c b/drivers/usb/core/urb.c
index da923ec17612..7fa23615199f 100644
--- a/drivers/usb/core/urb.c
+++ b/drivers/usb/core/urb.c
@@ -772,11 +772,12 @@ void usb_block_urb(struct urb *urb)
EXPORT_SYMBOL_GPL(usb_block_urb);
/**
- * usb_kill_anchored_urbs - cancel transfer requests en masse
+ * usb_kill_anchored_urbs - kill all URBs associated with an anchor
* @anchor: anchor the requests are bound to
*
- * this allows all outstanding URBs to be killed starting
- * from the back of the queue
+ * This kills all outstanding URBs starting from the back of the queue,
+ * with guarantee that no completer callbacks will take place from the
+ * anchor after this function returns.
*
* This routine should not be called by a driver after its disconnect
* method has returned.
@@ -784,6 +785,7 @@ EXPORT_SYMBOL_GPL(usb_block_urb);
void usb_kill_anchored_urbs(struct usb_anchor *anchor)
{
struct urb *victim;
+ int ret;
spin_lock_irq(&anchor->lock);
while (!list_empty(&anchor->urb_list)) {
@@ -798,6 +800,10 @@ void usb_kill_anchored_urbs(struct usb_anchor *anchor)
spin_lock_irq(&anchor->lock);
}
spin_unlock_irq(&anchor->lock);
+
+ ret = usb_wait_anchor_empty_timeout(anchor, 1000);
+
+ WARN(!ret, "Returning with non-empty anchor due to timeout");
Don't do a warn-on for things that can be triggered by userspace (i.e.
"bad USB device), as that can cause systems to reboot, and will get
caught by the syzbot testing tool.
This WARN is triggered only if the device driver has a bug. Explained
further below.
Also, will this cause things to take longer than they used to? What
race conditions is this going to cause? :)
The impact of the call to usb_wait_anchor_empty_timeout() is virtually
none. Almost always, it will return immediately, as the anchor's list
has just been emptied.
It's only if a URB happened to be in the middle of being completed, that
it will wait for this to finish, which should be practically unnoticed:
Completer calls should be quick, so 1000 ms is a huge overkill. If this
WARN gets into effect, it's because the driver's completer callback was
running for 1000ms. It's a bug in the driver. No faulty USB device
should be able to make this happen.
Alternatively, if the driver submits URBs to the same anchor while
usb_kill_anchored_urbs() is called, this timeout might be reached. This
could happen, for example, if the completer function that ran in the
racy situation resubmits the URB. If that situation isn't cleared within
1000ms, it means that there's a URB in the system that the driver isn't
aware of. Maybe that situation is worth more than a WARN.
I originally thought about a goto to the beginning of the function after
the WARN until the anchor's list is empty. But a really buggy driver
could turn that into an infinite loop.
Regards,
Eli
thanks,
greg k-h
