LinuxLists.cc - BUG: KASAN: use-after-free in xhci_trb_virt_to

2018-07-20 09:46:07

Subject: BUG: KASAN: use-after-free in xhci_trb_virt_to_dma.part.24+0x1c/0x80

Dear Linux folks,

Using Linux 4.18-rc5+ with kmemleak enabled on a MSI B350M MORTAR (MS-7A37)
with an AMD Ryzen 3 2200G, the memory leak below is suspected.

```
$ sudo less /sys/kernel/debug/kmemleak
unreferenced object 0xffff894f8874a2b8 (size 8):
comm "systemd-udevd", pid 119, jiffies 4294893109 (age 908.348s)
hex dump (first 8 bytes):
34 01 05 00 00 00 00 00 4.......
backtrace:
[<00000000308e4456>] xhci_init+0x81/0x170 [xhci_hcd]
[<00000000269aa18f>] xhci_gen_setup+0x2cb/0x510 [xhci_hcd]
[<000000007b70d85f>] xhci_pci_setup+0x4d/0x120 [xhci_pci]
[<0000000059f49127>] usb_add_hcd+0x2b6/0x800 [usbcore]
[<000000009a16d67c>] usb_hcd_pci_probe+0x1f3/0x460 [usbcore]
[<0000000001295c2e>] xhci_pci_probe+0x27/0x1d7 [xhci_pci]
[<00000000395bd8f9>] local_pci_probe+0x41/0x90
[<00000000a344e362>] pci_device_probe+0x189/0x1a0
[<00000000318999e5>] driver_probe_device+0x2b9/0x460
[<00000000c29d8a55>] __driver_attach+0xdd/0x110
[<00000000975b7f46>] bus_for_each_dev+0x76/0xc0
[<000000006bc40955>] bus_add_driver+0x152/0x230
[<00000000840ed63c>] driver_register+0x6b/0xb0
[<00000000123908c4>] do_one_initcall+0x46/0x1c3
[<00000000ce69c793>] do_init_module+0x5a/0x210
[<0000000091d4aef2>] load_module+0x21c4/0x2410
[…]
```

Kind regards,

Paul

Attachments:

smime.p7s (5.05 kB)
S/MIME Cryptographic Signature

2018-07-20 09:55:41

by Greg KH

[permalink] [raw]

Subject: Re: BUG: KASAN: use-after-free in xhci_trb_virt_to_dma.part.24+0x1c/0x80

On Fri, Jul 20, 2018 at 11:44:49AM +0200, Paul Menzel wrote:
> Dear Linux folks,
>
>
> Using Linux 4.18-rc5+ with kmemleak enabled on a MSI B350M MORTAR (MS-7A37)
> with an AMD Ryzen 3 2200G, the memory leak below is suspected.
>
> ```
> $ sudo less /sys/kernel/debug/kmemleak
> unreferenced object 0xffff894f8874a2b8 (size 8):
> comm "systemd-udevd", pid 119, jiffies 4294893109 (age 908.348s)
> hex dump (first 8 bytes):
> 34 01 05 00 00 00 00 00 4.......
> backtrace:
> [<00000000308e4456>] xhci_init+0x81/0x170 [xhci_hcd]
> [<00000000269aa18f>] xhci_gen_setup+0x2cb/0x510 [xhci_hcd]
> [<000000007b70d85f>] xhci_pci_setup+0x4d/0x120 [xhci_pci]
> [<0000000059f49127>] usb_add_hcd+0x2b6/0x800 [usbcore]
> [<000000009a16d67c>] usb_hcd_pci_probe+0x1f3/0x460 [usbcore]
> [<0000000001295c2e>] xhci_pci_probe+0x27/0x1d7 [xhci_pci]
> [<00000000395bd8f9>] local_pci_probe+0x41/0x90
> [<00000000a344e362>] pci_device_probe+0x189/0x1a0
> [<00000000318999e5>] driver_probe_device+0x2b9/0x460
> [<00000000c29d8a55>] __driver_attach+0xdd/0x110
> [<00000000975b7f46>] bus_for_each_dev+0x76/0xc0
> [<000000006bc40955>] bus_add_driver+0x152/0x230
> [<00000000840ed63c>] driver_register+0x6b/0xb0
> [<00000000123908c4>] do_one_initcall+0x46/0x1c3
> [<00000000ce69c793>] do_init_module+0x5a/0x210
> [<0000000091d4aef2>] load_module+0x21c4/0x2410
> […]
> ```

That's really vague. Any chance for a reproducer or some other types of
hints as to what you feel the problem is here?

thanks,

greg k-h

2018-07-23 11:25:11

by Paul Menzel

[permalink] [raw]

Subject: Re: BUG: KASAN: use-after-free in xhci_trb_virt_to_dma.part.24+0x1c/0x80

Dear Greg,

On 07/20/18 11:54, Greg KH wrote:
> On Fri, Jul 20, 2018 at 11:44:49AM +0200, Paul Menzel wrote:

>> Using Linux 4.18-rc5+ with kmemleak enabled on a MSI B350M MORTAR (MS-7A37)
>> with an AMD Ryzen 3 2200G, the memory leak below is suspected.
>>
>> ```
>> $ sudo less /sys/kernel/debug/kmemleak
>> unreferenced object 0xffff894f8874a2b8 (size 8):
>> comm "systemd-udevd", pid 119, jiffies 4294893109 (age 908.348s)
>> hex dump (first 8 bytes):
>> 34 01 05 00 00 00 00 00 4.......
>> backtrace:
>> [<00000000308e4456>] xhci_init+0x81/0x170 [xhci_hcd]
>> [<00000000269aa18f>] xhci_gen_setup+0x2cb/0x510 [xhci_hcd]
>> [<000000007b70d85f>] xhci_pci_setup+0x4d/0x120 [xhci_pci]
>> [<0000000059f49127>] usb_add_hcd+0x2b6/0x800 [usbcore]
>> [<000000009a16d67c>] usb_hcd_pci_probe+0x1f3/0x460 [usbcore]
>> [<0000000001295c2e>] xhci_pci_probe+0x27/0x1d7 [xhci_pci]
>> [<00000000395bd8f9>] local_pci_probe+0x41/0x90
>> [<00000000a344e362>] pci_device_probe+0x189/0x1a0
>> [<00000000318999e5>] driver_probe_device+0x2b9/0x460
>> [<00000000c29d8a55>] __driver_attach+0xdd/0x110
>> [<00000000975b7f46>] bus_for_each_dev+0x76/0xc0
>> [<000000006bc40955>] bus_add_driver+0x152/0x230
>> [<00000000840ed63c>] driver_register+0x6b/0xb0
>> [<00000000123908c4>] do_one_initcall+0x46/0x1c3
>> [<00000000ce69c793>] do_init_module+0x5a/0x210
>> [<0000000091d4aef2>] load_module+0x21c4/0x2410
>> […]
>> ```
>
> That's really vague. Any chance for a reproducer or some other types of
> hints as to what you feel the problem is here?

Unfortunately, not really. I have a SanDisk USB storage medium attached.

```
$ lsusb
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 002: ID 413c:3012 Dell Computer Corp. Optical Wheel Mouse
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 002: ID 0781:558b SanDisk Corp.
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 413c:2105 Dell Computer Corp. Model L100 Keyboard
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
```

After ten or eleven minutes after boot, systemd-udevd gets triggered
and causes the kmemleak message.

```
[ 82.196740] calling fuse_init+0x0/0x1a6 [fuse] @ 4455
[ 82.196741] fuse init (API version 7.27)
[ 82.201779] initcall fuse_init+0x0/0x1a6 [fuse] returned 0 after 4925 usecs
[ 677.532745] kmemleak: 3 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
```

Please note, that there could be memory corruption issues [1] with AMD
Raven devices. But as I can reproduce the kmemleak messages, I thought
that this is unrelated and that you might have an idea.

Please tell me, if I can provide more information. Sorry for
forgetting to attach the Linux messages.

Kind regards,

Paul

[1]: https://bugs.freedesktop.org/show_bug.cgi?id=105684
"Loading amdgpu hits general protection fault: 0000 [#1] SMP NOPTI"

Attachments:

=?utf-8?Q?20180723=E2=80=93linux-messages=2Etxt?= (146.54 kB)
smime.p7s (5.05 kB)
S/MIME Cryptographic Signature Download all attachments

2020-01-02 14:11:39

On 13.2.2020 15.33, Jon Hunter wrote:
>
> On 11/02/2020 15:01, Mathias Nyman wrote:
>> xhci driver assumed that xHC controllers have at most one custom
>> supported speed table (PSI) for all usb 3.x ports.
>> Memory was allocated for one PSI table under the xhci hub structure.
>>
>> Turns out this is not the case, some controllers have a separate
>> "supported protocol capability" entry with a PSI table for each port.
>> This means each usb3 roothub port can in theory support different custom
>> speeds.
>>
>> To solve this, cache all supported protocol capabilities with their PSI
>> tables in an array, and add pointers to the xhci port structure so that
>> every port points to its capability entry in the array.
>>
>> When creating the SuperSpeedPlus USB Device Capability BOS descriptor
>> for the xhci USB 3.1 roothub we for now will use only data from the
>> first USB 3.1 capable protocol capability entry in the array.
>> This could be improved later, this patch focuses resolving
>> the memory leak.
>>
>> Reported-by: Paul Menzel <[email protected]>
>> Reported-by: Sajja Venkateswara Rao <[email protected]>
>> Fixes: 47189098f8be ("xhci: parse xhci protocol speed ID list for usb 3.1 usage")
>> Cc: stable <[email protected]> # v4.4+
>> Signed-off-by: Mathias Nyman <[email protected]>
>
>
> Since next-20200211, we have been observing a regression exiting suspend
> on our Tegra124 Jetson TK1 board. Bisect is pointing to this commit and
> reverting on top of -next fixes the problem.
>
> On exiting suspend, I am seeing the following ...
>
> [ 56.216793] tegra-xusb 70090000.usb: Firmware already loaded, Falcon state 0x20
> [ 56.216834] usb usb3: root hub lost power or was reset
> [ 56.216837] usb usb4: root hub lost power or was reset
> [ 56.217760] tegra-xusb 70090000.usb: No ports on the roothubs?
> [ 56.218257] tegra-xusb 70090000.usb: failed to resume XHCI: -12
> [ 56.218299] PM: dpm_run_callback(): platform_pm_resume+0x0/0x40 returns -12
> [ 56.218312] PM: Device 70090000.usb failed to resume: error -12
> [ 56.334366] hub 4-0:1.0: hub_ext_port_status failed (err = -32)
> [ 56.334368] hub 3-0:1.0: hub_ext_port_status failed (err = -32)
>
> Let me know if you have any thoughts on this.
>
> Cheers
> Jon

This was an issue with the first version, and should be fixed in the second.

next-20200211 has the faulty version,
next-20200213 is fixed, reverted first version and applied second.

Does next-20200213 work for you?

-Mathias

2020-02-14 08:36:35

by Jon Hunter

[permalink] [raw]

Subject: Re: [RFT PATCH v2] xhci: Fix memory leak when caching protocol extended capability PSI tables

On 14/02/2020 07:47, Mathias Nyman wrote:
> On 13.2.2020 15.33, Jon Hunter wrote:
>>
>> On 11/02/2020 15:01, Mathias Nyman wrote:
>>> xhci driver assumed that xHC controllers have at most one custom
>>> supported speed table (PSI) for all usb 3.x ports.
>>> Memory was allocated for one PSI table under the xhci hub structure.
>>>
>>> Turns out this is not the case, some controllers have a separate
>>> "supported protocol capability" entry with a PSI table for each port.
>>> This means each usb3 roothub port can in theory support different custom
>>> speeds.
>>>
>>> To solve this, cache all supported protocol capabilities with their PSI
>>> tables in an array, and add pointers to the xhci port structure so that
>>> every port points to its capability entry in the array.
>>>
>>> When creating the SuperSpeedPlus USB Device Capability BOS descriptor
>>> for the xhci USB 3.1 roothub we for now will use only data from the
>>> first USB 3.1 capable protocol capability entry in the array.
>>> This could be improved later, this patch focuses resolving
>>> the memory leak.
>>>
>>> Reported-by: Paul Menzel <[email protected]>
>>> Reported-by: Sajja Venkateswara Rao <[email protected]>
>>> Fixes: 47189098f8be ("xhci: parse xhci protocol speed ID list for usb 3.1 usage")
>>> Cc: stable <[email protected]> # v4.4+
>>> Signed-off-by: Mathias Nyman <[email protected]>
>>
>>
>> Since next-20200211, we have been observing a regression exiting suspend
>> on our Tegra124 Jetson TK1 board. Bisect is pointing to this commit and
>> reverting on top of -next fixes the problem.
>>
>> On exiting suspend, I am seeing the following ...
>>
>> [ 56.216793] tegra-xusb 70090000.usb: Firmware already loaded, Falcon state 0x20
>> [ 56.216834] usb usb3: root hub lost power or was reset
>> [ 56.216837] usb usb4: root hub lost power or was reset
>> [ 56.217760] tegra-xusb 70090000.usb: No ports on the roothubs?
>> [ 56.218257] tegra-xusb 70090000.usb: failed to resume XHCI: -12
>> [ 56.218299] PM: dpm_run_callback(): platform_pm_resume+0x0/0x40 returns -12
>> [ 56.218312] PM: Device 70090000.usb failed to resume: error -12
>> [ 56.334366] hub 4-0:1.0: hub_ext_port_status failed (err = -32)
>> [ 56.334368] hub 3-0:1.0: hub_ext_port_status failed (err = -32)
>>
>> Let me know if you have any thoughts on this.
>>
>> Cheers
>> Jon
>
> This was an issue with the first version, and should be fixed in the second.
>
> next-20200211 has the faulty version,
> next-20200213 is fixed, reverted first version and applied second.
>
> Does next-20200213 work for you?

Yes it does. Sorry I am an idiot and should have read the changes and
thread more closely!

Thanks for fixing so quickly.

Jon

--
nvpublic