CVE-2026-45904

What it actually does

This is a Linux kernel availability flaw in the PowerPC EEH PCI error-handling path. A locking change caused eeh_handle_normal_event() to acquire pci_rescan_remove_lock and then call code that attempts to acquire the same lock again, producing recursive mutex acquisition and potential deadlock in the EEH daemon path. When triggered, PCI error recovery, device removal/rescan handling, or EEH event processing can stall, potentially leaving affected PCI devices unusable and degrading or halting services that depend on them. The issue is architecture- and subsystem-specific: it primarily affects Linux kernel builds running on PowerPC systems using EEH/PCI error handling.

Why it matters to the business

Successful exploitation can cause denial of service on affected PowerPC Linux systems by disrupting PCI device error handling and recovery. The most likely operational consequence is loss or instability of hardware-backed services such as storage, networking, accelerators, or other PCI-attached devices, which can lead to workload interruption or system unavailability. The vulnerability is not known to be in CISA KEV, is not reported as ransomware-used, has very low EPSS, and has no known public exploit maturity in the supplied data, so urgency is lower than internet-facing remote-code-execution issues; however, critical PowerPC systems with untrusted local users, PCI passthrough, or exposed device-management capabilities should still prioritize kernel updates.

How an attack unfolds

An attacker needs local access or a way to influence PCI/EEH event generation on an affected PowerPC Linux system. They attempt to trigger a PCI error, hotplug, removal/rescan, or EEH recovery path that causes the kernel EEH event handler to process a normal EEH event. In the vulnerable code path, the handler acquires pci_rescan_remove_lock and then reaches eeh_pe_bus_get(), which attempts to acquire the same lock again. Because the same task already holds the mutex, the kernel can deadlock or emit lockdep recursive-locking warnings. The result is disrupted EEH processing and possible failure of PCI recovery/removal operations, causing device loss, degraded service, or host-level availability impact. There is no indication from the supplied data that this enables privilege escalation, data theft, or remote compromise.

How to fix it

Upgrade to a Linux kernel version from the relevant distribution or upstream stable branch that includes the fix for the PowerPC EEH recursive pci_lock_rescan_remove locking issue. The corrected implementation avoids nested acquisition by using a no-lock wrapper where the caller already holds pci_rescan_remove_lock and restores lock acquisition to the correct scope around affected PCI device iteration/removal. No exact fixed package versions were provided, so use vendor advisories for the deployed distribution and kernel branch. If immediate patching is not possible, reduce exposure by limiting local shell access, restricting access to device-management interfaces, avoiding untrusted PCI passthrough on affected PowerPC systems, and monitoring for EEH/PCI recovery failures. Mitigations do not fully remove the risk because the flaw is in kernel synchronization logic.

How to confirm the fix worked

Confirm that affected systems are PowerPC Linux hosts using EEH-capable PCI hardware and a kernel version containing the vulnerable change. Validate remediation by checking the installed kernel package against the distribution advisory or upstream commit that fixes the EEH locking behavior. After patching and rebooting into the fixed kernel, exercise PCI error recovery or controlled hotplug/rescan workflows where safe and verify that no recursive-locking warnings, eehd stalls, or pci_rescan_remove_lock deadlock messages appear in kernel logs. Also confirm that PCI devices recover normally after EEH events and that the running kernel, not only the installed package, is updated.

Typical attack path

1. Obtain local low-privileged access to an affected PowerPC Linux system, or gain control over a PCI device or passthrough path capable of provoking EEH events.
2. Identify that the host uses the vulnerable Linux kernel code path for PowerPC EEH PCI error handling.
3. Trigger PCI error recovery, hotplug, remove/rescan, or another event that causes eeh_handle_normal_event() to execute.
4. Cause the EEH handler to acquire pci_rescan_remove_lock and then re-enter code that attempts to acquire the same lock through eeh_pe_bus_get().
5. Induce lock contention or deadlock in the eehd/kernel path, disrupting EEH event handling and PCI device recovery.
6. Leverage the resulting device or subsystem unavailability to interrupt dependent workloads or services.

How to detect it

Look for evidence of kernel recursive-locking warnings, eehd stalls, PCI EEH recovery failures, or device remove/rescan hangs on affected PowerPC hosts. Primary log sources are the kernel ring buffer, system journal, /var/log/kern.log, /var/log/messages, console logs, crash dumps, and monitoring alerts for PCI device loss. Search for lockdep output indicating possible recursive locking involving pci_rescan_remove_lock, especially with the eehd process and stack frames containing pci_lock_rescan_remove(), eeh_pe_bus_get(), or eeh_handle_normal_event(). Also review timelines for unexplained PCI device disappearances, failed hotplug/removal operations, repeated EEH events, storage path loss, network adapter resets, or workloads becoming unavailable immediately after PCI/EEH errors. Because this is a denial-of-service synchronization bug, there may be no attacker-specific artifact; detection is based on kernel behavior, local user activity around device-management operations, and correlation with service impact.

• WARNING: possible recursive locking detected
• *** DEADLOCK ***
• pci_rescan_remove_lock
• pci_lock_rescan_remove
• eeh_pe_bus_get
• eeh_handle_normal_event
• eehd/
• Comm: eehd
• powerpc/eeh
• EEH event
• broken PCI error reporting
• recursive pci_lock_rescan_remove locking
• /var/log/kern.log
• /var/log/messages

What your security team should do

• Inventory PowerPC Linux systems, especially IBM Power/pSeries environments, and identify kernels that include the affected EEH locking change.
• Prioritize patching systems that host critical workloads, use PCI passthrough, rely on storage/network PCI devices, or allow untrusted local users.
• Apply vendor-provided kernel updates and reboot into the fixed kernel; live patching may not be sufficient unless the vendor explicitly covers this synchronization fix.
• Until patched, restrict local access and device-control capabilities that could trigger PCI rescan, hotplug, or EEH recovery paths.
• Add monitoring for kernel lockdep warnings and EEH/PCI recovery failures on PowerPC hosts.
• Review recent outages or PCI device resets on affected systems for signs of recursive locking or eehd deadlock behavior.
• If recurring EEH failures are observed, collect kernel logs, dmesg output, kernel version, platform model, and PCI topology before remediation for incident review and vendor support.