{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:12",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "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 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.  [\u003c0\u003e] 0xc00000011c78f870 [\u003c0\u003e] __switch_to+0xfc/0x1a0 [\u003c0\u003e] pci_lock_rescan_remove+0x30/0x44 [\u003c0\u003e] eeh_rmv_device+0x290/0x2e0 [\u003c0\u003e] eeh_pe_dev_traverse+0x80/0x130 [\u003c0\u003e] eeh_reset_device+0xcc/0x23c [\u003c0\u003e] eeh_handle_normal_event+0x830/0xa80 [\u003c0\u003e] eeh_event_handler+0xf8/0x190 [\u003c0\u003e] kthread+0x194/0x1b0 [\u003c0\u003e] 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).",
  "id": "DEBIAN-CVE-2026-97948",
  "modified": "2026-09-26T04:47:40.177125166Z",
  "published": "2026-09-25T11:17:22.317Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-97948"
    }
  ],
  "upstream": [
    "CVE-2026-97948"
  ]
}