Messages in this thread |  | | Subject | Re: BUG: KASAN: use-after-free in xhci_trb_virt_to_dma.part.24+0x1c/0x80 | From | Mathias Nyman <> | Date | Wed, 8 Jan 2020 11:34:22 +0200 |
| |
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
|  |