PatchSiren

PatchSiren cyber security CVE debrief

CVE-2026-45904 Linux CVE debrief

A recursive locking vulnerability in the Linux kernel's PowerPC EEH (Enhanced Error Handling) driver can cause deadlock conditions and disrupt PCI error reporting on IBM Power systems. The issue stems from commit 1010b4c012b0, which restructured EEH driver synchronization with PCI hotplug but inadvertently moved pci_lock_rescan_remove() outside its intended scope in eeh_handle_normal_event(). This caused eeh_handle_normal_event() to acquire pci_lock_rescan_remove() before calling eeh_pe_bus_get(), which then attempted to acquire the same lock internally—resulting in nested locking that triggers lockdep warnings and potential deadlock. The vulnerability manifests as broken PCI error reporting and improper EEH event triggering. The fix introduces a boolean do_lock parameter to _eeh_pe_bus_get() with two public wrappers: eeh_pe_bus_get() (locking enabled) and eeh_pe_bus_get_nolock() (skips locking). Callers already holding pci_lock_rescan_remove() now use eeh_pe_bus_get_nolock() to avoid recursive acquisition. The pci_lock_rescan_remove() calls are restored to their correct position—after eeh_pe_bus_get() and immediately before iterating affected PEs and devices. Additionally, eeh_pe_loc_get() is split into eeh_pe_loc_get(struct eeh_pe *pe) and eeh_pe_loc_get_bus(struct pci_bus *bus). Multiple stable kernel branches have received patches.

Vendor
Linux
Product
Unknown
CVSS
Unknown
CISA KEV
Not listed in stored evidence
Original CVE published
2026-05-27
Original CVE updated
2026-05-27
Advisory published
2026-05-27
Advisory updated
2026-05-27

Who should care

Organizations running Linux on IBM Power systems (POWER8, POWER9, POWER10) with EEH enabled; kernel maintainers for PowerPC architectures; cloud providers offering Power-based instances; enterprises relying on PCI hotplug and error recovery on Power hardware

Technical summary

The vulnerability exists in arch/powerpc/kernel/eeh.c in the EEH (Enhanced Error Handling) driver. The problematic code path: eeh_handle_normal_event() calls pci_lock_rescan_remove(), then eeh_pe_bus_get(), which internally calls pci_lock_rescan_remove() again—causing recursive lock acquisition on pci_rescan_remove_lock (a mutex). The fix adds internal function _eeh_pe_bus_get(struct eeh_pe *pe, bool do_lock) with wrappers eeh_pe_bus_get() (do_lock=true) and eeh_pe_bus_get_nolock() (do_lock=false). In eeh_handle_normal_event(), the call pattern changes from: pci_lock_rescan_remove(); bus = eeh_pe_bus_get(pe); ... pci_unlock_rescan_remove(); to: bus = eeh_pe_bus_get_nolock(pe); pci_lock_rescan_remove(); ... pci_unlock_rescan_remove(); This ensures the lock is acquired only once. The eeh_pe_loc_get() refactoring separates PE-based and bus-based location code retrieval. Affected hardware: IBM Power systems (POWER8/9/10) using pSeries platform with EEH enabled. Lockdep warning signature: 'possible recursive locking detected' on pci_rescan_remove_lock with stack trace showing eehd task in eeh_pe_bus_get+0x48/0xc0.

Defensive priority

medium

Recommended defensive actions

  • Apply kernel patches from stable branches (6.12, 6.14, 6.15, 6.18-rc) to resolve recursive locking in EEH driver
  • Monitor dmesg for lockdep warnings indicating recursive pci_rescan_remove_lock acquisition on PowerPC systems
  • If running affected kernels on IBM Power hardware, plan maintenance window for kernel update to prevent EEH event handling failures
  • Verify EEH functionality after patching by checking proper PCI error reporting and hotplug synchronization

Evidence notes

CVE description confirms recursive locking in pci_rescan_remove_lock within eeh_handle_normal_event() → eeh_pe_bus_get() call chain. Lockdep warning shows same lock address c000000003b29d58 acquired twice. Fix involves adding do_lock parameter with eeh_pe_bus_get_nolock() wrapper for callers already holding the lock.

Official resources

2026-05-27