CVE-2026-97948: powerpc/eeh: Fix recursive locking on devices without EEH sensitive driver

Published Sep 25, 2026
·
Updated

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

powerpc/eeh: Fix recursive locking on devices without EEH sensitive driver

The commit 1010b4c012b0 ("powerpc/eeh: Make EEH driver device hotplug safe") refactored the EEH code such that the pcirescanremovelock is held at the beginning of eehhandlenormalevent() and the eehresetdevice() is called with that lock being held. Looks like the commit missed to remove the existing lock/unlock inside eehrmvdevice() which is no longer necessary. This is causing the eehd to hang on the lock which it actually holds when that code path is taken.

[<0>] 0xc00000011c78f870 [<0>] switchto+0xfc/0x1a0 [<0>] pcilockrescanremove+0x30/0x44 [<0>] eehrmvdevice+0x290/0x2e0 [<0>] eehpedevtraverse+0x80/0x130 [<0>] eehresetdevice+0xcc/0x23c [<0>] eehhandlenormalevent+0x830/0xa80 [<0>] eeheventhandler+0xf8/0x190 [<0>] kthread+0x194/0x1b0 [<0>] startkernelthread+0x14/0x18

The issue is seen for cases where the errors are detected on the PHB directly AND|OR for devices where the driver errordetected() returns PCIERSRESULTNEEDRESET, and driver being not EEH sensitive(i.e no error handlers like slotreset(), resume() etc defined).

Affected Software

1 affected component
Linux Linux kernel

Event History

Sep 25, 2026
CVE Published
via MITRE·10:22 AM
Data Sourced
via MITRE·10:22 AM
Description
Data Sourced
via NVD·11:17 AM
Description

Frequently Asked Questions

1

Which systems are exposed to the hang condition?

The affected path is in the Linux kernel powerpc EEH error-handling code. It is seen when errors are detected directly on the PHB, or when a device driver's error_detected() callback returns PCI_ERS_RESULT_NEED_RESET and that driver is not EEH-sensitive.

2

What driver behavior makes the problem more likely to occur?

The described case requires a driver without EEH error handlers such as slot_reset() and resume(). If that driver requests a reset through PCI_ERS_RESULT_NEED_RESET, EEH can enter the affected removal path.

3

How can I recognize an affected system?

The EEH daemon, eehd, can hang while waiting on pci_rescan_remove_lock that it already holds. A kernel stack trace may show pci_lock_rescan_remove(), eeh_rmv_device(), eeh_reset_device(), eeh_handle_normal_event(), and eeh_event_handler().

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203