Re: UAF during boot on MTL based devices with attached dock

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Mika,

the logs I shared with Ilpo a few minutes ago will already contain activated thunderbolt logging.

Thank you & best regards,
Dennis


On Mon, 2024-09-23 at 07:41 +0300, mika.westerberg@xxxxxxxxxxxxxxx wrote:
> Hi,
> 
> On Thu, Sep 19, 2024 at 08:06:03AM +0000, Wassenberg, Dennis wrote:
> > Hi together,
> > 
> > we are facing into issues which seems to be PCI related and asking for your estimations.
> > 
> > Background:
> > We want to boot up an Intel MeteorLake based system (e.g. Lenovo ThinkPad X13 Gen5) with the Lenovo Thunderbolt 4
> > universal dock attached during boot. On some devices it is nearly 100% reproducible that the boot will fail. Other
> > systems will never show this issue (e.g. older devices based on RaptorLake or AlderLake platform).
> > 
> > We did some debugging on this and came to the conclusion that there is a use-after-free in pci_slot_release.
> > The Thunderbolt 4 Dock will expose a PCI hierarchy at first and shortly after that, due to the device is
> > inaccessible,
> > it will release the additional buses/ports. This seems to end up in a race where pci_slot_release accesses &slot-
> > >bus
> > which as already freed:
> > 
> > 0000:00 [root bus]
> >       -> 0000:00:07.0 [bridge to 20-49]
> >                      -> 0000:20:00.0 [bridge to 21-49]
> >                                     -> 0000:21:00.0 [bridge to 22]
> >                                        0000:21:01.0 [bridge to 23-2e]
> >                                        0000:21:02.0 [bridge to 2f-3a]
> >                                        0000:21:03.0 [bridge to 3b-48]
> >                                        0000:21:04.0 [bridge to 49]
> >          0000:00:07.2 [bridge to 50-79]
> > 
> > 
> > We are currently running on kernel 6.8.12. Because this kernel is out of support I tried it on 6.11. This kernel
> > shows
> > exactly the same issue. I attached two log files:
> > dmesg-ramoops-0: Based on kernel 6.11 with added kernel command line option "slab_debug" in order to force a kernel
> > Oops
> > while accessing freed memory.
> > dmesg-ramoops-0-pci_dbg: This it like dmesg-ramoops-0 with additional kernel command line option '"dyndbg=file
> > drivers/pci/* +p" ignore_loglevel' in order to give you more insight whats happening on the pci bus.
> 
> Can you run the same with the v6.11 but add also "thunderbolt.dyndbg=+p"
> in the kernel command line and provide me that log?





[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux