CVE-2026-45904
Awaiting Analysis Awaiting Analysis - Queue
Recursive Locking in Linux Kernel EEH Subsystem

Publication date: 2026-05-27

Last updated on: 2026-05-27

Assigner: kernel.org

Description
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: <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 (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---
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-05-27
Last Modified
2026-05-27
Generated
2026-06-16
AI Q&A
2026-05-27
EPSS Evaluated
2026-06-15
NVD
EUVD
Affected Vendors & Products
Showing 2 associated CPEs
Vendor Product Version / Range
linux linux_kernel 6.18.0-rc3
linux_kernel linux_kernel 6.18.0-rc3
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Quick Actions
Instant insights powered by AI
Executive Summary

This vulnerability is related to the Linux kernel's powerpc EEH (Enhanced Error Handling) driver. A recent change intended to improve synchronization with the PCI hotplug layer inadvertently caused a recursive locking issue with pci_lock_rescan_remove(). Specifically, the function eeh_handle_normal_event() acquired a lock before calling eeh_pe_bus_get(), but eeh_pe_bus_get() also tries to acquire the same lock internally, leading to nested locking and broken PCI error reporting.

This recursive locking can cause deadlocks and disrupt normal EEH event handling, which is critical for proper PCI error detection and handling. The fix involved adding a parameter to control locking behavior in eeh_pe_bus_get(), splitting functions to avoid recursive lock acquisition, and restoring lock calls to their correct positions to prevent deadlocks.

Impact Analysis

This vulnerability can lead to broken PCI error reporting and improper handling of EEH events in the Linux kernel on powerpc systems. As a result, PCI devices may not be correctly removed or rescanned during error events, potentially causing system instability, hardware errors to go unnoticed, or deadlocks in the kernel.

Such issues can affect system reliability and availability, especially in environments relying on PCI hotplug and error handling mechanisms.

Detection Guidance

This vulnerability manifests as recursive locking issues in the Linux kernel's EEH driver, which can cause lockdep warnings and deadlock scenarios.

To detect this vulnerability on your system, you can monitor the kernel logs for warnings related to recursive locking of pci_rescan_remove_lock and deadlock messages.

Specifically, look for log entries similar to:

  • WARNING: possible recursive locking detected
  • Deadlock involving pci_rescan_remove_lock

You can use the following command to check the kernel log for such messages:

  • dmesg | grep -i 'pci_rescan_remove_lock'
  • dmesg | grep -i 'recursive locking'
  • dmesg | grep -i 'deadlock'

Additionally, monitoring system logs (e.g., /var/log/kern.log or journalctl) for these warnings can help detect the issue.

Mitigation Strategies

The vulnerability is caused by improper recursive locking in the EEH driver within the Linux kernel.

Immediate mitigation involves updating the Linux kernel to a version that includes the patch fixing this issue.

The patch restructures the EEH driver to avoid recursive locking by properly positioning pci_lock_rescan_remove() calls and introducing locking parameters to prevent nested lock acquisition.

If updating the kernel is not immediately possible, monitoring for deadlock warnings and avoiding workloads that trigger EEH events may reduce the risk of system instability.

Ultimately, applying the official patch or upgrading to a fixed kernel version is the recommended step.

Chat Assistant
Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-45904. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70
EPSS Chart