* [RFC PATCH] xhci: Fix memory use after free in xhci_free_virt_device
@ 2016-11-15 20:36 Guenter Roeck
2016-11-17 15:11 ` Mathias Nyman
0 siblings, 1 reply; 2+ messages in thread
From: Guenter Roeck @ 2016-11-15 20:36 UTC (permalink / raw)
To: Mathias Nyman
Cc: Greg Kroah-Hartman, dianders, briannorris, mka, linux-usb,
linux-kernel, Guenter Roeck
The following use-after-free reports were seen on resume with a specific
USB hub.
BUG: KASAN: use-after-free in xhci_free_virt_device+0x8c/0x21c
at addr ffffffc0cc1a2eb0
BUG: KASAN: use-after-free in xhci_update_tt_active_eps+0x9c/0xdc
at addr ffffffc0cc1a2eb0
Relevant traceback for the first case is:
xhci_free_virt_device+0x8c/0x21c
xhci_mem_cleanup+0x294/0x81c
xhci_resume+0x410/0x618
xhci_plat_resume+0x54/0x74
platform_pm_resume+0x74/0x84
which points to the following code in xhci_free_virt_device().
if (dev->tt_info)
old_active_eps = dev->tt_info->active_eps;
Problem with this code is that xhci_mem_cleanup() cleans up devices
starting with slot 1, and dev->tt_info for a device with higher slot
number can point back to the tt_info associated with device 1.
In lsusb, this looks as follows.
/: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
|__ Port 1: Dev 4, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 3: Dev 7, If 0, Class=Vendor Specific Class, Driver=, 12M
When the higher-numbered device is cleared, it tries to access the already
released tt_info from slot 1 to get the value of old_active_eps.
The problem is not seen with all USB hubs since not all USB hubs require
the cleanup handling in xhci_resume().
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
---
Marked as RFC because I don't really like this fix at all and would prefer
a different solution.
It might be possible, for example, to change the code in xhci_mem_cleanup()
from
for (i = 1; i < MAX_HC_SLOTS; ++i)
xhci_free_virt_device(xhci, i);
to
for (i = MAX_HC_SLOTS - 1; i >= 1; i--)
xhci_free_virt_device(xhci, i);
if it is guaranteed that tt_info never points to a device with higher slot
number.
drivers/usb/host/xhci-mem.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 6afe32381209..97a61c57a2ed 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -873,8 +873,14 @@ static void xhci_free_tt_info(struct xhci_hcd *xhci,
list_for_each_entry_safe(tt_info, next, tt_list_head, tt_list) {
/* Multi-TT hubs will have more than one entry */
if (tt_info->slot_id == slot_id) {
+ int i;
+
slot_found = true;
list_del(&tt_info->tt_list);
+ for (i = 0; i < MAX_HC_SLOTS; i++)
+ if (xhci->devs[i] &&
+ xhci->devs[i]->tt_info == tt_info)
+ xhci->devs[i]->tt_info = NULL;
kfree(tt_info);
} else if (slot_found) {
break;
--
2.5.0
^ permalink raw reply related [flat|nested] 2+ messages in thread
* Re: [RFC PATCH] xhci: Fix memory use after free in xhci_free_virt_device
2016-11-15 20:36 [RFC PATCH] xhci: Fix memory use after free in xhci_free_virt_device Guenter Roeck
@ 2016-11-17 15:11 ` Mathias Nyman
0 siblings, 0 replies; 2+ messages in thread
From: Mathias Nyman @ 2016-11-17 15:11 UTC (permalink / raw)
To: Guenter Roeck, Mathias Nyman
Cc: Greg Kroah-Hartman, dianders, briannorris, mka, linux-usb,
linux-kernel
On 15.11.2016 22:36, Guenter Roeck wrote:
> The following use-after-free reports were seen on resume with a specific
> USB hub.
>
> BUG: KASAN: use-after-free in xhci_free_virt_device+0x8c/0x21c
> at addr ffffffc0cc1a2eb0
> BUG: KASAN: use-after-free in xhci_update_tt_active_eps+0x9c/0xdc
> at addr ffffffc0cc1a2eb0
>
> Relevant traceback for the first case is:
>
> xhci_free_virt_device+0x8c/0x21c
> xhci_mem_cleanup+0x294/0x81c
> xhci_resume+0x410/0x618
> xhci_plat_resume+0x54/0x74
> platform_pm_resume+0x74/0x84
>
> which points to the following code in xhci_free_virt_device().
>
> if (dev->tt_info)
> old_active_eps = dev->tt_info->active_eps;
>
> Problem with this code is that xhci_mem_cleanup() cleans up devices
> starting with slot 1, and dev->tt_info for a device with higher slot
> number can point back to the tt_info associated with device 1.
> In lsusb, this looks as follows.
>
> /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
> |__ Port 1: Dev 4, If 0, Class=Hub, Driver=hub/4p, 480M
> |__ Port 3: Dev 7, If 0, Class=Vendor Specific Class, Driver=, 12M
>
> When the higher-numbered device is cleared, it tries to access the already
> released tt_info from slot 1 to get the value of old_active_eps.
>
> The problem is not seen with all USB hubs since not all USB hubs require
> the cleanup handling in xhci_resume().
>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> ---
Thanks, nice catch.
> Marked as RFC because I don't really like this fix at all and would prefer
> a different solution.
>
I just started digging into this and see if I can come up with some solution.
It's currently a bit messy the whole thing how the tt_info and bw_table are
allocated, freed, pointed to and added and removed to/from lists
-Mathias
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2016-11-17 17:37 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-11-15 20:36 [RFC PATCH] xhci: Fix memory use after free in xhci_free_virt_device Guenter Roeck
2016-11-17 15:11 ` Mathias Nyman
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox