CVE-2026-97948 Linux CVE debrief

Who should care

Defenders responsible for Linux kernel configurations, especially for powerpc systems using EEH, should assess exposure and prioritize verification of Linux kernel configurations for EEH handling. They should also verify that EEH-sensitive drivers are correctly implemented and configured, and monitor system logs for signs of EEH-related issues. Additionally, defenders should review compensating controls for exposed systems while remediation is scheduled,

Why it matters

A locking issue in the Linux kernel's EEH code for powerpc systems can cause a hang when errors are detected, requiring defenders to assess exposure and prioritize verification.

• Potential system hang or lockup on powerpc systems with EEH errors
• Need for verification of Linux kernel configurations for EEH handling
• Possible impact on system availability and reliability

Technical summary

The Linux kernel's EEH (Error Handling) code for powerpc systems has a locking issue that can cause a hang when errors are detected on PHBs or devices without EEH-sensitive drivers. This is due to a refactoring commit (1010b4c012b0) that introduced a recursive lock in eeh_handle_normal_event(), conflicting with existing lock/unlock calls in eeh_rmv_device(). The issue is seen for cases where the errors are detected on the PHB directly AND/OR for devices where the driver error_detected() returns PCI_ERS_RESULT_NEED_RESET, and driver being not EEH sensitive.

Defensive priority

Defenders should assess exposure and prioritize verification of Linux kernel configurations, especially for powerpc systems using EEH.

Recommended defensive actions

• Review Linux kernel configurations for powerpc systems to ensure EEH is properly handled
• Verify that EEH-sensitive drivers are correctly implemented and configured
• Monitor system logs for signs of EEH-related issues
• Confirm whether affected product deployments exist in managed environments and assign an owner for follow-up
• Review the supplied official advisory or CVE record to validate affected scope, severity, and vendor guidance
• Plan vendor-supported updates or mitigations through normal change control where exposure is confirmed
• Check relevant monitoring, detection, and logs for exposed assets that need extra review

Evidence notes

The issue arises from a refactoring commit (1010b4c012b0) that introduced a recursive lock in eeh_handle_normal_event(), which is called with pci_rescan_remove_lock held. This conflicts with existing lock/unlock calls in eeh_rmv_device(), leading to a potential hang in eehd.

Sources and references

Methodology and review provenance

AI-assisted synthesis based on stored public vulnerability evidence. System validation, approval state, and publication status do not by themselves establish human review of this revision. PatchSiren helps prioritize defensive review and does not prove exposure or remediation on any system.