Re: BUG: BISECTED: drivers/usb/host/xhci: memleak in alloc from xhci_disable_usb3_lpm_timeout()

[Mirsad Goran Todorovac <mirsad.todorovac@alu.unizg.hr>]

On 27. 03. 2023. 11:41, Mathias Nyman wrote:
> On 25.3.2023 13.33, Mirsad Goran Todorovac wrote:
>> On 25. 03. 2023. 12:27, Mirsad Goran Todorovac wrote:
>>> Hi all!
>>>
>>> Here are again the good news and the bad news:
>>>
>>> BAD:  another kernel memory leak detected (one more to hunt down and fix)
>>> GOOD: another kernel memory leak detected (one less unaccounted for)
>>>
>>> I tried to make some fun, but maintainers are busy folks, so let's get down
>>> to business:
>>>
>>> ---
>>> Nine (9) new systemd-udevd kernel memory leaks occurred (unable to reproduce).
>>>
>>> The platform is Ubuntu 22.10 with (relatively recent) systemd 251.4-1ubuntu7.1
>>> on LENOVO_MT_82H8_BU_idea_FM_IdeaPad 3 15ITL6 with BIOS GGCN51WW from 11/16/2022.
>>>
>>> The symptom (/sys/kernel/debug/kmemleak output):
>>>
>>> unreferenced object 0xffff909698ff9280 (size 64):
>>>    comm "systemd-udevd", pid 436, jiffies 4294893239 (age 6287.088s)
>>>    hex dump (first 32 bytes):
>>>      e0 51 bb 99 96 90 ff ff 00 00 00 00 00 00 00 00  .Q..............
>>>      40 5b bb 99 96 90 ff ff 00 00 00 00 00 00 00 00  @[..............
>>>    backtrace:
>>>      [<ffffffffb29de94c>] slab_post_alloc_hook+0x8c/0x320
>>>      [<ffffffffb29e5107>] __kmem_cache_alloc_node+0x1c7/0x2b0
>>>      [<ffffffffb2962f3b>] kmalloc_node_trace+0x2b/0xa0
>>>      [<ffffffffb31af2ec>] xhci_alloc_command+0x7c/0x1b0
>>>      [<ffffffffb31af451>] xhci_alloc_command_with_ctx+0x21/0x70
>>>      [<ffffffffb31a8a3e>] xhci_change_max_exit_latency+0x2e/0x1c0>>      [<ffffffffb31a8c5b>] xhci_disable_usb3_lpm_timeout+0x7b/0xb0
>>>      [<ffffffffb31457a7>] usb_disable_link_state+0x57/0xe0
> 
> Thanks for the report.
> 
> I think I found the leak, and wrote a patch for it.
> Any chance you could test it with the same setup?
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git/commit/?h=for-usb-linus&id=8bacee588602ed74cc22aaf4c56b796300e5a943

As I have already been half-through bisect, I took the liberty to finish it.

# good: [5ce036b98dd3301fc43bb06a6383ef07b6c776bc] xhci: dbc: create and remove dbc structure in dbgtty driver.
git bisect good 5ce036b98dd3301fc43bb06a6383ef07b6c776bc
# bad: [d016cbe4d7acf5100df83ecf4d02db4e9f607c1d] usb: typec: Support the WUSB3801 port controller
git bisect bad d016cbe4d7acf5100df83ecf4d02db4e9f607c1d
# bad: [cd36facf104afbde7e8fa25cd6f5b6dd9fa97bb2] usb: remove Link Powermanagement (LPM) disable before port reset.
git bisect bad cd36facf104afbde7e8fa25cd6f5b6dd9fa97bb2
# good: [6aec50009d52f28ef8b512cba0f5078b3928064d] xhci: dbc: Don't call dbc_tty_init() on every dbc tty probe
git bisect good 6aec50009d52f28ef8b512cba0f5078b3928064d
# bad: [5c2a380a5aa8c15985359904b6d47466528d2993] xhci: Allocate separate command structures for each LPM command
git bisect bad 5c2a380a5aa8c15985359904b6d47466528d2993
# good: [e1ec140f273e1e30cea7e6d5f50934d877232121] xhci: dbgtty: use IDR to support several dbc instances.
git bisect good e1ec140f273e1e30cea7e6d5f50934d877232121
# first bad commit: [5c2a380a5aa8c15985359904b6d47466528d2993] xhci: Allocate separate command structures for each LPM command

Interesting enough, Mr. Greg predicted this is an xhci problem already in November [1],
but I did not embolden myself to bisect until this weekend, seeing that it was
still leaking.

But then I was brand new to the CONFIG_DEBUG_KMEMLEAK feature.

[1] https://lore.kernel.org/lkml/Y2zCYwNNvQWppLWZ@kroah.com/

I think the culprit patch is otherwise awesome, reducing latency and locking, especially
welcome in multimedia use.

So far, I was unable to exploit this leak as non-superuser or automate it like gpio-sim
to exhaust the kernel's limited memory, but this doesn't prove that smarter hackers
couldn't devise some means to do that exploit.

BTW: Full designation of the patch is 5.17.0-rc4-kmemlk-xhci-00071-g5c2a380a5aa8, so all
kernels 5.17-rc4+ appear affected by the issue.

Thank you and if you will need any more testing, I am available in my off hours.

Really nice working to assist your dynamic team.

To compare, another developer from another project was desperate about a software giant
being unwilling to abandon deprecated MODP 1024 DH renegotiation for its native VPN,
now for a couple of years ...

Best regards,
Mirsad

-- 
Mirsad Goran Todorovac
Sistem inženjer
Grafički fakultet | Akademija likovnih umjetnosti
Sveučilište u Zagrebu
 
System engineer
Faculty of Graphic Arts | Academy of Fine Arts
University of Zagreb, Republic of Croatia
The European Union

"I see something approaching fast ... Will it be friends with me?"