PT-2026-43771 · Linux · Linux

Published

2026-05-27

·

Updated

2026-05-27

·

CVE-2026-45904

None

No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
In the Linux kernel, the following vulnerability has been resolved:
powerpc/eeh: fix recursive pci lock rescan remove locking in EEH event handling
The recent commit 1010b4c012b0 ("powerpc/eeh: Make EEH driver device hotplug safe") restructured the EEH driver to improve synchronization with the PCI hotplug layer.
However, it inadvertently moved pci lock rescan remove() outside its intended scope in eeh handle normal event(), leading to broken PCI error reporting and improper EEH event triggering. Specifically, eeh handle normal event() acquired pci lock rescan remove() before calling eeh pe bus get(), but eeh pe bus get() itself attempts to acquire the same lock internally, causing nested locking and disrupting normal EEH event handling paths.
This patch adds a boolean parameter do lock to eeh pe bus get(), with two public wrappers: eeh pe bus get() with locking enabled. eeh pe bus get nolock() that skips locking.
Callers that already hold pci lock rescan remove() now use eeh pe bus get nolock() to avoid recursive lock acquisition.
Additionally, pci lock rescan remove() calls are restored to the correct position—after eeh pe bus get() and immediately before iterating affected PEs and devices. This ensures EEH-triggered PCI removes occur under proper bus rescan locking without recursive lock contention.
The eeh pe loc get() function has been split into two functions: eeh pe loc get(struct eeh pe *pe) which retrieves the loc for given PE. eeh pe loc get bus(struct pci bus *bus) which retrieves the location code for given bus.
This resolves lockdep warnings such as: [ 84.964298] [ T928] ============================================ [ 84.964304] [ T928] WARNING: possible recursive locking detected [ 84.964311] [ T928] 6.18.0-rc3 #51 Not tainted [ 84.964315] [ T928] -------------------------------------------- [ 84.964320] [ T928] eehd/928 is trying to acquire lock: [ 84.964324] [ T928] c000000003b29d58 (pci rescan remove lock){+.+.}-{3:3}, at: pci lock rescan remove+0x28/0x40 [ 84.964342] [ T928] but task is already holding lock: [ 84.964347] [ T928] c000000003b29d58 (pci rescan remove lock){+.+.}-{3:3}, at: pci lock rescan remove+0x28/0x40 [ 84.964357] [ T928] other info that might help us debug this: [ 84.964363] [ T928] Possible unsafe locking scenario:
[ 84.964367] [ T928] CPU0 [ 84.964370] [ T928] ---- [ 84.964373] [ T928] lock(pci rescan remove lock); [ 84.964378] [ T928] lock(pci rescan remove lock); [ 84.964383] [ T928] *** DEADLOCK ***
[ 84.964388] [ T928] May be due to missing lock nesting notation
[ 84.964393] [ T928] 1 lock held by eehd/928: [ 84.964397] [ T928] #0: c000000003b29d58 (pci rescan remove lock){+.+.}-{3:3}, at: pci lock rescan remove+0x28/0x40 [ 84.964408] [ T928] stack backtrace: [ 84.964414] [ T928] CPU: 2 UID: 0 PID: 928 Comm: eehd Not tainted 6.18.0-rc3 #51 VOLUNTARY [ 84.964417] [ T928] Hardware name: IBM,9080-HEX POWER10 (architected) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060 022) hv:phyp pSeries [ 84.964419] [ T928] Call Trace: [ 84.964420] [ T928] [c0000011a7157990] [c000000001705de4] dump stack lvl+0xc8/0x130 (unreliable) [ 84.964424] [ T928] [c0000011a71579d0] [c0000000002f66e0] print deadlock bug+0x430/0x440 [ 84.964428] [ T928] [c0000011a7157a70] [c0000000002fd0c0] lock acquire+0x1530/0x2d80 [ 84.964431] [ T928] [c0000011a7157ba0] [c0000000002fea54] lock acquire+0x144/0x410 [ 84.964433] [ T928] [c0000011a7157cb0] [c0000011a7157cb0] mutex lock+0xf4/0x1050 [ 84.964436] [ T928] [c0000011a7157e00] [c000000000de21d8] pci lock rescan remove+0x28/0x40 [ 84.964439] [ T928] [c0000011a7157e20] [c00000000004ed98] eeh pe bus get+0x48/0xc0 [ 84.964442] [ T928] [c0000011a7157e50] [c00000 ---truncated---

Related Identifiers

CVE-2026-45904

Affected Products

Linux