CVE-2026-45904 Overview
CVE-2026-45904 is a recursive locking flaw in the Linux kernel's PowerPC Enhanced Error Handling (EEH) subsystem. The defect was introduced by commit 1010b4c012b0 ("powerpc/eeh: Make EEH driver device hotplug safe"), which restructured the EEH driver to improve synchronization with the PCI hotplug layer. The change inadvertently moved pci_lock_rescan_remove() outside its intended scope inside eeh_handle_normal_event(), producing nested acquisition of the same lock and breaking PCI error reporting paths. Lockdep flags the condition as a potential deadlock on POWER systems handling EEH events.
Critical Impact
Recursive acquisition of pci_rescan_remove_lock during EEH event handling can deadlock the eehd kernel thread, disrupting PCI error recovery on PowerPC systems.
Affected Products
- Linux kernel PowerPC (powerpc/eeh) subsystem
- Linux kernel 6.18-rc series (reproduced on 6.18.0-rc3)
- IBM POWER platforms using EEH (for example, POWER10 pSeries under PHYP)
Discovery Timeline
- 2026-05-27 - CVE-2026-45904 published to NVD
- 2026-05-27 - Last updated in NVD database
Technical Details for CVE-2026-45904
Vulnerability Analysis
The issue is a recursive locking defect classified as a race condition / deadlock flaw in kernel locking discipline. Inside eeh_handle_normal_event(), the code acquires pci_lock_rescan_remove() before calling eeh_pe_bus_get(). However, eeh_pe_bus_get() itself attempts to acquire the same pci_rescan_remove_lock internally. The result is a nested lock acquisition on a non-recursive mutex, which lockdep detects and reports as WARNING: possible recursive locking detected.
Beyond the lockdep warning, the misplaced lock acquisition disturbs the normal EEH event handling path. PCI error reporting becomes unreliable, and EEH-triggered PCI device removals no longer execute under the correct bus rescan locking scope. On affected systems, the eehd thread can stall while attempting to take a lock it already holds.
Root Cause
The root cause is the placement of pci_lock_rescan_remove() introduced by commit 1010b4c012b0. The lock is acquired too early in eeh_handle_normal_event(), encompassing a call to eeh_pe_bus_get() that performs its own internal locking. Because pci_rescan_remove_lock is a non-reentrant mutex, the second acquisition by the same task triggers a deadlock condition.
Attack Vector
The defect is reachable through normal kernel operation on PowerPC hardware when an EEH event fires against a PCI device. No remote attack vector is documented. Exploitation requires conditions that trigger EEH event handling, such as PCI bus errors on POWER platforms. The flaw manifests as availability impact (stall or deadlock of the EEH handler thread) rather than memory corruption or privilege escalation.
The upstream fix introduces a boolean do_lock parameter to _eeh_pe_bus_get() and exposes two wrappers: eeh_pe_bus_get() with locking enabled and eeh_pe_bus_get_nolock() that skips locking. Callers that already hold pci_lock_rescan_remove() switch to the nolock variant. The patch also splits eeh_pe_loc_get() into eeh_pe_loc_get(struct eeh_pe *pe) and eeh_pe_loc_get_bus(struct pci_bus *bus). See the Linux Kernel Commit f8b16d5 for the canonical fix.
Detection Methods for CVE-2026-45904
Indicators of Compromise
- Lockdep messages in dmesg containing WARNING: possible recursive locking detected referencing pci_rescan_remove_lock.
- Call stacks showing pci_lock_rescan_remove+0x28/0x40 invoked from eeh_pe_bus_get inside the eehd kernel thread.
- Stalled or unresponsive eehd worker on PowerPC systems following PCI error events.
Detection Strategies
- Audit running kernel versions on POWER hosts to identify builds that include commit 1010b4c012b0 but lack the fix commits listed in the kernel.org references.
- Enable CONFIG_PROVE_LOCKING / lockdep on test kernels to surface the recursive acquisition before production exposure.
- Inspect journalctl -k and serial console logs from POWER LPARs for the deadlock backtrace pattern shown in the upstream report.
Monitoring Recommendations
- Centralize PowerPC kernel logs and alert on recursive locking detected or pci_rescan_remove_lock strings.
- Track health of the eehd thread and PCI error recovery counters on POWER systems to detect handler stalls.
- Monitor kernel package versions across the fleet and flag PowerPC nodes pending the EEH locking fix.
How to Mitigate CVE-2026-45904
Immediate Actions Required
- Apply the upstream Linux kernel fix containing the eeh_pe_bus_get_nolock() wrapper and the corrected pci_lock_rescan_remove() placement.
- Prioritize patching PowerPC systems running affected 6.18-rc kernels or distribution backports that include commit 1010b4c012b0.
- Rebuild and redeploy custom kernels for POWER workloads after merging the stable fix.
Patch Information
The vulnerability is resolved by upstream commits available on git.kernel.org, including Linux Kernel Commit 6e65612, Linux Kernel Commit 788dd28, Linux Kernel Commit 815a8d2, Linux Kernel Commit 87a1f93, Linux Kernel Commit 89810e2, Linux Kernel Commit b85ee28, Linux Kernel Commit f49faa4, and Linux Kernel Commit f8b16d5. Consume the fix from your distribution's stable kernel update channel where available.
Workarounds
- No supported configuration-level workaround exists; the locking defect lives in kernel code paths that cannot be disabled without losing EEH functionality.
- Where patching is delayed, restrict workloads that generate frequent PCI errors on affected POWER LPARs to limit exposure to the deadlock condition.
- Maintain console access and out-of-band recovery for affected POWER nodes so that stalled eehd threads can be diagnosed and the system recovered.
# Verify kernel version and check for the fix on a PowerPC host
uname -srm
dmesg | grep -iE 'recursive locking|pci_rescan_remove_lock|eeh'
# Confirm distribution package version contains the EEH locking fix
rpm -q kernel || dpkg -l | grep linux-image
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
