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@xxxxxxxxxxxx> ---
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 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html