<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://vulnerability.circl.lu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-09-28T20:56:37.072273+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@circl.lu</email>
  </author>
  <link href="https://vulnerability.circl.lu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/cve-2026-97948</id>
    <title>CVE-2026-97948 — powerpc/eeh: Fix recursive locking on devices without EEH sensitive driver</title>
    <updated>2026-09-28T20:56:37.075878+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Linux</p>
<p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>powerpc/eeh: Fix recursive locking on devices without EEH sensitive driver</p>
<p>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.</p>
<p>[&lt;0&gt;] 0xc00000011c78f870
[&lt;0&gt;] __switch_to+0xfc/0x1a0
[&lt;0&gt;] pci_lock_rescan_remove+0x30/0x44
[&lt;0&gt;] eeh_rmv_device+0x290/0x2e0
[&lt;0&gt;] eeh_pe_dev_traverse+0x80/0x130
[&lt;0&gt;] eeh_reset_device+0xcc/0x23c
[&lt;0&gt;] eeh_handle_normal_event+0x830/0xa80
[&lt;0&gt;] eeh_event_handler+0xf8/0x190
[&lt;0&gt;] kthread+0x194/0x1b0
[&lt;0&gt;] start_kernel_thread+0x14/0x18</p>
<p>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).</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/cve-2026-97948"/>
  </entry>
</feed>
