From: "Krzysztof Wilczyński" <kw@linux.com>
To: Lukas Wunner <lukas@wunner.de>
Cc: Bjorn Helgaas <helgaas@kernel.org>,
linux-pci@vger.kernel.org,
Wouter Bijlsma <wouter@wouterbijlsma.nl>,
Ilpo Jarvinen <ilpo.jarvinen@linux.intel.com>,
Mika Westerberg <mika.westerberg@linux.intel.com>
Subject: Re: [PATCH] PCI/bwctrl: Fix NULL pointer deref on bus number exhaustion
Date: Sun, 23 Mar 2025 20:24:56 +0900 [thread overview]
Message-ID: <20250323112456.GA1902347@rocinante> (raw)
In-Reply-To: <3b6c8d973aedc48860640a9d75d20528336f1f3c.1742669372.git.lukas@wunner.de>
Hello,
> When BIOS neglects to assign bus numbers to PCI bridges, the kernel
> attempts to correct that during PCI device enumeration. If it runs out
> of bus numbers, no pci_bus is allocated and the "subordinate" pointer in
> the bridge's pci_dev remains NULL.
>
> The PCIe bandwidth controller erroneously does not check for a NULL
> subordinate pointer and dereferences it on probe.
>
> Bandwidth control of unusable devices below the bridge is of questionable
> utility, so simply error out instead. This mirrors what PCIe hotplug does
> since commit 62e4492c3063 ("PCI: Prevent NULL dereference during pciehp
> probe").
>
> The PCI core emits a message with KERN_INFO severity if it has run out of
> bus numbers. PCIe hotplug emits an additional message with KERN_ERR
> severity to inform the user that hotplug functionality is disabled at the
> bridge. A similar message for bandwidth control does not seem merited,
> given that its only purpose so far is to expose an up-to-date link speed
> in sysfs and throttle the link speed on certain laptops with limited
> Thermal Design Power. So error out silently.
>
> User-visible messages:
>
> pci 0000:16:02.0: bridge configuration invalid ([bus 00-00]), reconfiguring
> [...]
> pci_bus 0000:45: busn_res: [bus 45-74] end is updated to 74
> pci 0000:16:02.0: devices behind bridge are unusable because [bus 45-74] cannot be assigned for them
> [...]
> pcieport 0000:16:02.0: pciehp: Hotplug bridge without secondary bus, ignoring
> [...]
> BUG: kernel NULL pointer dereference
> RIP: pcie_update_link_speed
> pcie_bwnotif_enable
> pcie_bwnotif_probe
> pcie_port_probe_service
> really_probe
Applied to bwctrl, thank you!
Krzysztof
next prev parent reply other threads:[~2025-03-23 11:24 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-22 18:52 [PATCH] PCI/bwctrl: Fix NULL pointer deref on bus number exhaustion Lukas Wunner
2025-03-23 11:24 ` Krzysztof Wilczyński [this message]
[not found] ` <2e16d6af-7d7d-47a7-9c69-26f0765a83d6@app.fastmail.com>
2025-03-23 12:56 ` Krzysztof Wilczyński
2025-03-23 13:07 ` Wouter Bijlsma
2025-03-23 13:39 ` Krzysztof Wilczyński
2025-04-04 13:06 ` Ilpo Järvinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250323112456.GA1902347@rocinante \
--to=kw@linux.com \
--cc=helgaas@kernel.org \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=linux-pci@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=mika.westerberg@linux.intel.com \
--cc=wouter@wouterbijlsma.nl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox