GHSA-WGJ5-J7WG-2JM2
Vulnerability from github – Published: 2026-09-25 12:31 – Updated: 2026-09-25 12:31In 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 pci_rescan_remove_lock is held at the beginning of eeh_handle_normal_event() and the eeh_reset_device() is called with that lock being held. Looks like the commit missed to remove the existing lock/unlock inside eeh_rmv_device() 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>] __switch_to+0xfc/0x1a0 [<0>] pci_lock_rescan_remove+0x30/0x44 [<0>] eeh_rmv_device+0x290/0x2e0 [<0>] eeh_pe_dev_traverse+0x80/0x130 [<0>] eeh_reset_device+0xcc/0x23c [<0>] eeh_handle_normal_event+0x830/0xa80 [<0>] eeh_event_handler+0xf8/0x190 [<0>] kthread+0x194/0x1b0 [<0>] start_kernel_thread+0x14/0x18
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(i.e no error handlers like slot_reset(), resume() etc defined).
{
"affected": [],
"aliases": [
"CVE-2026-97948"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-25T11:17:22Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/eeh: Fix recursive locking on devices without EEH sensitive driver\n\nThe commit 1010b4c012b0 (\"powerpc/eeh: Make EEH driver device hotplug\nsafe\") refactored the EEH code such that the pci_rescan_remove_lock is\nheld at the beginning of eeh_handle_normal_event() and the\neeh_reset_device() is called with that lock being held. Looks like the\ncommit missed to remove the existing lock/unlock inside eeh_rmv_device()\nwhich is no longer necessary. This is causing the eehd to hang on the\nlock which it actually holds when that code path is taken.\n\n[\u003c0\u003e] 0xc00000011c78f870\n[\u003c0\u003e] __switch_to+0xfc/0x1a0\n[\u003c0\u003e] pci_lock_rescan_remove+0x30/0x44\n[\u003c0\u003e] eeh_rmv_device+0x290/0x2e0\n[\u003c0\u003e] eeh_pe_dev_traverse+0x80/0x130\n[\u003c0\u003e] eeh_reset_device+0xcc/0x23c\n[\u003c0\u003e] eeh_handle_normal_event+0x830/0xa80\n[\u003c0\u003e] eeh_event_handler+0xf8/0x190\n[\u003c0\u003e] kthread+0x194/0x1b0\n[\u003c0\u003e] start_kernel_thread+0x14/0x18\n\nThe issue is seen for cases where the errors are detected on the PHB\ndirectly AND|OR for devices where the driver error_detected() returns\nPCI_ERS_RESULT_NEED_RESET, and driver being not EEH sensitive(i.e no\nerror handlers like slot_reset(), resume() etc defined).",
"id": "GHSA-wgj5-j7wg-2jm2",
"modified": "2026-09-25T12:31:29Z",
"published": "2026-09-25T12:31:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-97948"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/102e3dc5ab5ba052e294819e83384166b242c1ec"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2920af33d097ca335e492b346af70b72986ad6dc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/85d8eaefc052cf3e5ae2c7bafeda2db68b8898b4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c5e68706527968282e49de205cc2b935823cb88a"
}
],
"schema_version": "1.4.0",
"severity": []
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.