From: Mathias Nyman <mathias.nyman@linux.intel.com>
To: Guenter Roeck <linux@roeck-us.net>,
Mathias Nyman <mathias.nyman@intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
dianders@chromium.org, briannorris@chromium.org,
mka@chromium.org, linux-usb@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH] xhci: Fix memory use after free in xhci_free_virt_device
Date: Thu, 17 Nov 2016 17:11:08 +0200 [thread overview]
Message-ID: <582DC88C.5040308@linux.intel.com> (raw)
In-Reply-To: <1479242199-3241-1-git-send-email-linux@roeck-us.net>
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
prev parent reply other threads:[~2016-11-17 17:37 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
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 message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=582DC88C.5040308@linux.intel.com \
--to=mathias.nyman@linux.intel.com \
--cc=briannorris@chromium.org \
--cc=dianders@chromium.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=mathias.nyman@intel.com \
--cc=mka@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox