From: Mathias Nyman <mathias.nyman@linux.intel.com>
To: Paul Menzel <pmenzel@molgen.mpg.de>,
Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: Greg KH <greg@kroah.com>, Mathias Nyman <mathias.nyman@intel.com>,
linux-usb@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: BUG: KASAN: use-after-free in xhci_trb_virt_to_dma.part.24+0x1c/0x80
Date: Wed, 8 Jan 2020 11:34:22 +0200 [thread overview]
Message-ID: <572bea6f-06d4-938a-802e-93386acf59d9@linux.intel.com> (raw)
In-Reply-To: <84369435-d355-0462-98ab-91bb1c5d3871@molgen.mpg.de>
On 7.1.2020 17.35, Paul Menzel wrote:
> Dear Mathias, dear Mika,
>
>
> On 2020-01-07 13:09, Mathias Nyman wrote:
>> On 3.1.2020 13.04, Mika Westerberg wrote:
>>> On Thu, Jan 02, 2020 at 03:10:14PM +0100, Paul Menzel wrote:
>>>> Mika, as you fixed the other leak, any idea, how to continue from the
>>>> kmemleak log below?
>>>>
>>>> ```
>>>> unreferenced object 0xffff8c207a1e1408 (size 8):
>>>> comm "systemd-udevd", pid 183, jiffies 4294667978 (age 752.292s)
>>>> hex dump (first 8 bytes):
>>>> 34 01 05 00 00 00 00 00 4.......
>>>> backtrace:
>>>> [<00000000aea7b46d>] xhci_mem_init+0xcfa/0xec0 [xhci_hcd]
>>>
>>> There are probably better ways for doing this but you can use objdump
>>> for example:
>>>
>>> $ objdump -l --prefix-addresses -j .text --disassemble=xhci_mem_init drivers/usb/host/xhci-hcd.ko
>>>
>>> then find the offset xhci_mem_init+0xcfa. It should show you the line
>>> numbers as well if you have compiled your kernel with debug info. This
>>> should be close to the line that allocated the memory that was leaked.
>
> Thank you. I actually remembered `script/f2addr2line`.
>
> $ scripts/faddr2line drivers/usb/host/xhci-hcd.o xhci_mem_init+0xcfa
> xhci_mem_init+0xcfa/0xec0:
> xhci_add_in_port at /mnt/drivers/usb/host/xhci-mem.c:2161
> (inlined by) xhci_setup_port_arrays at /mnt/drivers/usb/host/xhci-mem.c:2309
> (inlined by) xhci_mem_init at /mnt/drivers/usb/host/xhci-mem.c:2538
>
>> Paul, it possible that your xhci controller has several
>> supported protocol extended capabilities for usb 3 ports, each
>> with their own custom protocol speed ID table.
>>
>> xhci driver assumes there is only one custome PSI table per roothub,
>> and we will end up allocating the second PSI table on top of the first,
>> leaking the first.
>>
>> Could you boot with xhci dynamic debug enabled, and show dmesg after boot, add:
>> xhci_hcd.dyndbg=+p
>> to you kernel cmdline.
>>
>> Or as an alternative, show output of:
>>
>> sudo cat /sys/kernel/debug/usb/xhci/*/reg-ext-protocol*
>
> `/sys/kernel/debug/` cannot be read by unprivileged users, so the wildcard does
> not work with `sudo`.
>
> ```
> $ sudo ls /sys/kernel/debug/usb/xhci
> 0000:12:00.0 0000:26:00.3 0000:26:00.4
> # cat /sys/kernel/debug/usb/xhci/*/reg-ext-protocol*
problematic xhci:
capability for first four USB 2 ports
> EXTCAP_REVISION = 0x02000402
> EXTCAP_NAME = 0x20425355
> EXTCAP_PORTINFO = 0x00180401
> EXTCAP_PORTTYPE = 0x00000000
capability for one USB 3.1 port (5th port)
> EXTCAP_REVISION = 0x03100802
> EXTCAP_NAME = 0x20425355
> EXTCAP_PORTINFO = 0x10000105
> EXTCAP_PORTTYPE = 0x00000000
> EXTCAP_MANTISSA1 = 0x00050134
capability for one USB 3.1 port (6th port)
> EXTCAP_REVISION = 0x03100802
> EXTCAP_NAME = 0x20425355
> EXTCAP_PORTINFO = 0x10000106
> EXTCAP_PORTTYPE = 0x00000000
> EXTCAP_MANTISSA1 = 0x00050134
capability for one USB 3.1 port (7th port)
> EXTCAP_REVISION = 0x03100802
> EXTCAP_NAME = 0x20425355
> EXTCAP_PORTINFO = 0x10000107
> EXTCAP_PORTTYPE = 0x00000000
> EXTCAP_MANTISSA1 = 0x00050134
capability for one USB 3.1 port (8th port)
> EXTCAP_REVISION = 0x03100802
> EXTCAP_NAME = 0x20425355
> EXTCAP_PORTINFO = 0x10000108
> EXTCAP_PORTTYPE = 0x00000000
> EXTCAP_MANTISSA1 = 0x00050134
It has eight ports. last four of them are USB 3.1 ports.
It has a very odd setup where each 3.1 port has their own
supported protocol capability with a custom PSI, but all the PSI's are similar,
telling the port only support a 5Gbps speed.
We leak all the custom PSI tables for USB 3.1 ports except the last,
these would be the EXTCAP_MANTISSA1 = 0x00050134, which is the same as
the hex dump of the unreferenced object you posted earlier (considering byte order):
hex dump (first 8 bytes):
34 01 05 00 00 00 00 00 4.......
I'm working on a patch for this
-Mathias
next prev parent reply other threads:[~2020-01-08 9:32 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-20 9:44 BUG: KASAN: use-after-free in xhci_trb_virt_to_dma.part.24+0x1c/0x80 Paul Menzel
2018-07-20 9:54 ` Greg KH
2018-07-23 11:23 ` Paul Menzel
2020-01-02 14:10 ` Paul Menzel
2020-01-03 11:04 ` Mika Westerberg
2020-01-07 12:09 ` Mathias Nyman
2020-01-07 15:35 ` Paul Menzel
2020-01-08 9:34 ` Mathias Nyman [this message]
2020-01-08 15:17 ` [RFT PATCH] xhci: Fix memory leak when caching protocol extended capability PSI tables Mathias Nyman
2020-01-08 15:40 ` Greg KH
2020-01-08 15:56 ` Mathias Nyman
[not found] ` <CGME20200211105613eucas1p27cac4202c4287a5967b2ed988779d523@eucas1p2.samsung.com>
2020-02-11 10:56 ` Marek Szyprowski
2020-02-11 12:23 ` Greg KH
2020-02-11 12:29 ` Mathias Nyman
2020-02-11 14:08 ` Mathias Nyman
2020-02-11 15:01 ` [RFT PATCH v2] " Mathias Nyman
2020-02-11 15:12 ` Marek Szyprowski
2020-02-11 16:13 ` Greg KH
2020-02-12 9:01 ` Mathias Nyman
2020-02-12 17:51 ` Greg KH
2020-02-13 13:33 ` Jon Hunter
2020-02-14 7:47 ` Mathias Nyman
2020-02-14 8:35 ` Jon Hunter
2020-01-09 8:53 ` BUG: KASAN: use-after-free in xhci_trb_virt_to_dma.part.24+0x1c/0x80 Felipe Balbi
-- strict thread matches above, loose matches on Subject: below --
2018-01-28 21:43 Paul Menzel
2018-01-29 11:48 ` Mathias Nyman
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=572bea6f-06d4-938a-802e-93386acf59d9@linux.intel.com \
--to=mathias.nyman@linux.intel.com \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mathias.nyman@intel.com \
--cc=mika.westerberg@linux.intel.com \
--cc=pmenzel@molgen.mpg.de \
/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;
as well as URLs for NNTP newsgroup(s).