Re: [PATCH] PCI/ASPM: Add missing NULL check for link in sysfs show/store callbacks

[Bjorn Helgaas <helgaas@kernel.org>]

[+cc other members of conversation at
https://lore.kernel.org/all/20260727072915.3954329-1-zhaojinming@uniontech.com]

On Wed, Nov 04, 2026 at 03:22:51PM -0800, Poulin, Louis wrote:
> Hi,
> 
> We observed a cold-boot crash in l0s_aspm_show() that appears to
> contradict the assumption in this thread that the visibility check
> always keeps readers out when the ASPM link is unavailable.
> 
> This was on an ASUS TUF GAMING X870-PLUS WIFI, BIOS 1805, running
> Bazzite's 7.2.15-ogc1.1.fc45.x86_64 kernel with InputPlumber 0.83.1.
> The fault occurred about 10 seconds into a cold boot. An earlier boot
> on the same system had the same fault address and symbol offset on
> 7.2.9-ogc3.1.fc44.x86_64 with InputPlumber 0.83.0. Both observations
> were on downstream kernels. The captured 7.2.15 kernel was tainted
> O/E (out-of-tree and unsigned module).
> 
> Relevant excerpt from 7.2.15:
> 
>   BUG: kernel NULL pointer dereference, address: 0000000000000030
>   Comm: inputplumber
>   RIP: 0010:l0s_aspm_show+0x47/0x80
>   RAX: 0000000000000000
>   CR2: 0000000000000030
>   Call Trace:
>     dev_attr_show+0x1f/0x50
>     sysfs_kf_seq_show+0xa8/0x110
>     seq_read_iter+0x132/0x4c0
>     vfs_read+0x34d/0x490
> 
> The faulting instruction accesses offset 0x30 from the NULL register.
> In the corresponding source, aspm_attr_show_common() dereferences the
> result of pcie_aspm_get_link(). The read reached the callback even
> though that lookup had no link to return. The kernel killed the
> InputPlumber main thread and the service stopped answering
> ObjectManager.GetManagedObjects. This blocked the boot-time controller
> setup.
> 
> We are building a diagnostic kernel that returns -ENODEV in that
> specific read callback when the link is absent and logs the PCI device
> and upstream bridge. The device and the reason its link state was
> missing are still unknown. We have not reproduced the fault on an
> unmodified upstream kernel.
> 
> Would this trace justify a guard in the read callback, or is there a
> preferred way to instrument link-state teardown and sysfs visibility
> on this hardware? We can follow up with the device and bridge once
> captured.

I don't think we should add a guard in addition to
aspm_ctrl_attrs_are_visible().

pcie_aspm_get_link() must have returned non-NULL in
aspm_ctrl_attrs_are_visible() for the sysfs file to be visible.

If it later returned NULL in aspm_attr_show_common(), we must have a
bug, like a lifetime issue or some kind of corruption.  Adding a guard
would just hide the bug.

Your next message suggests that the device and upstream bridge are
valid, so possibly bridge->link_state was NULL.  I would instrument
pcie_aspm_get_link() to verify that and add a dump_stack() in
free_link_state().

> Kernel source for the captured build
> https://github.com/OpenGamingCollective/linux/blob/f6857d4bfd614b90302903490796ef376be0a67d/drivers/pci/pcie/aspm.c
> 
> Thanks,
> Louis