linux-kernel - Re: [RFC PATCH] xhci: Fix memory use after free in xhci_free_virt

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Thu, 17 Nov 2016 17:11:08 +0200
From:   Mathias Nyman <mathias.nyman@...ux.intel.com>
To:     Guenter Roeck <linux@...ck-us.net>,
        Mathias Nyman <mathias.nyman@...el.com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        dianders@...omium.org, briannorris@...omium.org, mka@...omium.org,
        linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] xhci: Fix memory use after free in
 xhci_free_virt_device

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@...ck-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