CVE-2026-45904

In the Linux kernel, the following vulnerability has been resolved:

powerpc/eeh: fix recursive pcilockrescan_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 pcilockrescanremove() outside its intended scope in eehhandlenormalevent(), leading to broken PCI error reporting and improper EEH event triggering. Specifically, eehhandlenormalevent() acquired pcilockrescanremove() before calling eehpebusget(), but eehpebusget() itself attempts to acquire the same lock internally, causing nested locking and disrupting normal EEH event handling paths.

This patch adds a boolean parameter dolock to eehpebusget(), with two public wrappers: eehpebusget() with locking enabled. eehpebusgetnolock() that skips locking.

Callers that already hold pcilockrescanremove() now use eehpebusget_nolock() to avoid recursive lock acquisition.

Additionally, pcilockrescanremove() calls are restored to the correct position—after eehpebusget() 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 eehpelocget() function has been split into two functions: eehpelocget(struct eehpe *pe) which retrieves the loc for given PE. eehpelocgetbus(struct pcibus *bus) which retrieves the location code for given bus.

This resolves lockdep warnings such as: <snip> [ 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 (pcirescanremovelock){+.+.}-{3:3}, at: pcilockrescanremove+0x28/0x40 [ 84.964342] [ T928] but task is already holding lock: [ 84.964347] [ T928] c000000003b29d58 (pcirescanremovelock){+.+.}-{3:3}, at: pcilockrescanremove+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(pcirescanremovelock); [ 84.964378] [ T928] lock(pcirescanremovelock); [ 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 (pcirescanremovelock){+.+.}-{3:3}, at: pcilockrescanremove+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 (NH1060022) hv:phyp pSeries [ 84.964419] [ T928] Call Trace: [ 84.964420] [ T928] [c0000011a7157990] [c000000001705de4] dumpstacklvl+0xc8/0x130 (unreliable) [ 84.964424] [ T928] [c0000011a71579d0] [c0000000002f66e0] printdeadlock_bug+0x430/0x440 [ 84.964428] [ T928] [c0000011a7157a70] [c0000000002fd0c0] __lockacquire+0x1530/0x2d80 [ 84.964431] [ T928] [c0000011a7157ba0] [c0000000002fea54] lockacquire+0x144/0x410 [ 84.964433] [ T928] [c0000011a7157cb0] [c0000011a7157cb0] _mutexlock+0xf4/0x1050 [ 84.964436] [ T928] [c0000011a7157e00] [c000000000de21d8] pcilockrescanremove+0x28/0x40 [ 84.964439] [ T928] [c0000011a7157e20] [c00000000004ed98] eehpebusget+0x48/0xc0 [ 84.964442] [ T928] [c0000011a7157e50] [c00000 ---truncated---