From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754853AbcKQRho (ORCPT ); Thu, 17 Nov 2016 12:37:44 -0500 Received: from mga05.intel.com ([192.55.52.43]:44053 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754518AbcKQRhk (ORCPT ); Thu, 17 Nov 2016 12:37:40 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,506,1473145200"; d="scan'208";a="5595455" Subject: Re: [RFC PATCH] xhci: Fix memory use after free in xhci_free_virt_device To: Guenter Roeck , Mathias Nyman References: <1479242199-3241-1-git-send-email-linux@roeck-us.net> Cc: Greg Kroah-Hartman , dianders@chromium.org, briannorris@chromium.org, mka@chromium.org, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org From: Mathias Nyman Message-ID: <582DC88C.5040308@linux.intel.com> Date: Thu, 17 Nov 2016 17:11:08 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <1479242199-3241-1-git-send-email-linux@roeck-us.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > --- 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