Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - powerpc/eeh：修复 EEH 事件处理中的递归pci_lock_rescan_remove锁定 最近的提交 1010b4c012b0（powerpc/eeh：使 EEH 驱动程序设备热插拔安全）重构了 EEH 驱动程序以改进与 PCI 热插拔层的同步。但是，它不慎将 pci_lock_rescan_remove（） 移出其在 eeh_handle_normal_event（） 中的预期范围，导致 PCI 错误报告中断和不正确的 EEH 事件触发。具体而言，eeh_handle_normal_event（） 在调用 eeh_pe_bus_get（） 前就已获取 pci_lock_rescan_remove（），但 eeh_pe_bus_get（） 本身却尝试在内部获取相同的锁定，造成嵌套锁定并中断正常的 EEH 事件处理路径。此修补程序将布尔参数do_lock添加到具有两个公共封装程序的 _eeh_pe_bus_get（）：启用锁定的 eeh_pe_bus_get（）。
    跳过锁定的 eeh_pe_bus_get_nolock（）。已持有 pci_lock_rescan_remove（） 的调用程序现在使用 eeh_pe_bus_get_nolock（） 来避免递归锁定获取。此外，pci_lock_rescan_remove（） 调用会在 eeh_pe_bus_get（） 之后和迭代受影响的 PE 和设备之前立即还原到正确位置。这可确保在适当的总线重新扫描锁定下，EEH 触发的 PCI 删除发生，而不发生递归锁争夺。eeh_pe_loc_get（） 函数已拆分为两个函数：
    eeh_pe_loc_get（struct eeh_pe *pe），用于检索指定 PE 的 loc。eeh_pe_loc_get_bus（struct pci_bus
    *bus），用于检索给定总线的位置代码。这解决了 lockdep 警告，例如 [84.964298] [ T928] ============================================ [ 84.964304] T928[ ] 警告：检测到可能的递归锁定 [ 84.964311] [ T928] 6.18.0-rc3 #51 未受感染 [ 84.964315] [ T928] <snip>
    -------------------------------------------- [ 84.964320] T928[ ] eehd/928 正在尝试获取锁定： [84.964324] [ T928] c000000003b29d58 （pci_rescan_remove_lock）{+.+.}-{3:3}， at：
    pci_lock_rescan_remove+0x28/0x40 [ 84.964342] T928[ ] 但任务已经保持锁定： [ 84.964347] [T928] c000000003b29d58 （pci_rescan_remove_lock）{+.+.}-{3:3}， at： pci_lock_rescan_remove+0x28/0x40 [84.964357] T928[ ] 其他可能有助于我们调试此问题的信息： [ 84.964363] [ ] T928[ ] 可能的不安全锁定场景： [ 84.964367] [ T928] CPU0 [ 84.964370] [ T928] ---- [ 84.964373] T928[ ] lock（pci_rescan_remove_lock）;[ 84.964378] [ T928] 锁（pci_rescan_remove_lock）;[ 84.964383] [ T928] *** 死锁 *** [ 84.964388] [ ] 可能是 T928因为缺少锁定嵌套符号所致 [ 84.964393] [ T928] eehd/928 持有的 1 个锁定： [ 84.964397] [ T928] #0： c000000003b29d58 （pci_rescan_remove_lock）{+.+.}-{3:3}， at：
    pci_lock_rescan_remove+0x28/0x40 [ 84.964408] T928[ ] 堆栈回溯： [ 84.964414] [ T928] CPU：2 UID：0 PID：928 通信：eehd 未受感染 6.18.0-rc3 #51 VOLUNTARY [ 84.964417] [ T928] 硬件名称：IBM，9080-HEX POWER10 （architected） 0x800200 0xf000006 of：IBM，FW1060.00 （NH1060_022） hv：phyp pSeries [ 84.964419] [] 调用T928跟踪： [ 84.964420] [ T928] [c0000011a7157990] [c000000001705de4] dump_stack_lvl+0xc8/0x130（不可靠） [ 84.964424] [ T928] [c0000011a71579d0] [c0000000002f66e0] print_deadlock_bug+0x430/0x440 [84.964428] [ T928] [c0000011a7157a70] [c0000000002fd0c0] __lock_acquire+0x1530/0x2d80 [ 84.964431] [ T928] [c0000011a7157ba0] [c0000000002fea54] lock_acquire+0x144/0x410 ： [ 84.964433] [ T928] [c0000011a7157cb0] [c0000011a7157cb0] __mutex_lock+0xf4/0x1050 [ 84.964436] [ T928] [c0000011a7157e00] [c00000000de21d8] pci_lock_rescan_remove+0x28/0x40 [ 84.964439] [ T928] [c0000011a7157e20] [c00000000004ed98] eeh_pe_bus_get+0x48/0xc0 [ 84.964442] [ T928] [c0000011a7157e50] [c00000 ---truncated--- （CVE-2026-45904）

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且供應商未提供可用的修補程式。

  - powerpc/eeh：修正 EEH 事件處理中的遞迴pci_lock_rescan_remove鎖定 最近的提交 1010b4c012b0 （powerpc/eeh：使 EEH 驅動程式裝置熱插拔安全） 重組了 EEH 驅動程式，以改善與 PCI 熱插拔層的同步。然而，它無意中將 pci_lock_rescan_remove（） 移出了 eeh_handle_normal_event（） 中的預期範圍，導致 PCI 錯誤報告中斷和不當觸發 EEH 事件。具體來說，eeh_handle_normal_event（） 在調用 eeh_pe_bus_get（） 之前獲取了 pci_lock_rescan_remove（），但 eeh_pe_bus_get（） 本身嘗試在內部獲取相同的鎖，從而導致巢狀鎖定並中斷正常的 EEH 事件處理路徑。此修補程式將布林參數do_lock新增至 _eeh_pe_bus_get（），並具有兩個公開包裝函式：啟用鎖定的 eeh_pe_bus_get（）。
    跳過鎖定的 eeh_pe_bus_get_nolock（）。已持有 pci_lock_rescan_remove（） 的呼叫端現在使用 eeh_pe_bus_get_nolock（） 來避免遞迴鎖定取得。此外，pci_lock_rescan_remove（） 呼叫會在 eeh_pe_bus_get（） 之後和反覆運算受影響的 PE 和裝置之前還原到正確的位置。這可確保在適當的匯流排重新掃描鎖定下發生 EEH 觸發的 PCI 移除，而不會發生遞迴鎖定爭用。eeh_pe_loc_get（） 函數已拆分為兩個函數：
    eeh_pe_loc_get（struct eeh_pe *pe），擷取指定 PE 的 loc。eeh_pe_loc_get_bus（struct pci_bus
    *bus），以擷取指定匯流排的位置代碼。這解決了 lockdep 警告，例如： <snip> [] [ T928] ============================================ [ 84.964304] [ T928] 警告：偵測到可能的遞迴鎖定 [ 84.964311] [ T928] 6.18.0-rc3 #51 未受污染 [ 84.964315] [ T92884.964298]
    -------------------------------------------- [ 84.964320] T928[ ] eehd/928 正在嘗試取得鎖定： [84.964324] [ T928] c000000003b29d58 （pci_rescan_remove_lock）{+.+.}-{3:3}，位於：
    pci_lock_rescan_remove+0x28/0x40 [ 84.964342] T928[ ] 但任務已處於鎖定狀態： [ 84.964347] [T928] c000000003b29d58 （pci_rescan_remove_lock）{+.+.}-{3:3}， at： pci_lock_rescan_remove+0x28/0x40 [84.964357] T928[ ] 其他可能有助於我們偵錯的資訊： [ 84.964363] [ T928] [ ] 可能的不安全鎖定場景： [ 84.964367] [ T928] CPU0 [ 84.964370] [ T928] ---- [ 84.964373] [ T928] lock（pci_rescan_remove_lock）;[ 84.964378] [ T928] lock（pci_rescan_remove_lock）;[ 84.964383] [ T928] *** 鎖死 *** [ 84.964388] [ T928] 可能是因為缺少鎖定巢狀表示法 [ 84.964393] [ ] 1 T928個由 EEHD/928 持有的鎖定： [ 84.964397] [ T928] #0： c000000003b29d58 （pci_rescan_remove_lock）{+.+.}-{3:3}，位於：
    pci_lock_rescan_remove+0x28/0x40 [ 84.964408] T928[ ] 堆疊回溯：[ 84.964414] [ T928] CPU：2 UID：0 PID：928 通訊：eehd 未受污染 6.18.0-rc3 #51 自願性 [ 84.964417] [ T928] 硬體名稱：IBM，9080-HEX POWER10 （架構） 0x800200 0xf000006：IBM，FW1060.00 （NH1060_022） hv：phyp pSeries [ 84.964419] [] 呼叫T928追蹤：[ 84.964420] [ T928] [c0000011a7157990] [c000000001705de4] dump_stack_lvl+0xc8/0x130 （不可靠） [ 84.964424] [ T928] [c0000011a71579d0] [c0000000002f66e0] print_deadlock_bug+0x430/0x440 [84.964428] [ T928] [c0000011a7157a70] [c0000000002fd0c0] __lock_acquire+0x1530/0x2d80 [ 84.964431] [ T928] [c0000011a7157ba0] [c0000000002fea54] lock_acquire+0x144/0x410 [ 84.964433] [ T928] [c0000011a7157cb0] [c0000011a7157cb0] __mutex_lock+0xf4/0x1050 [ 84.964436] [ T928] [c0000011a7157e00] [c000000000de21d8] pci_lock_rescan_remove+0x28/0x40 [ 84.964439] [ T928] [c0000011a7157e20] [c00000000004ed98] eeh_pe_bus_get+0x48/0xc0 [ 84.964442] [ T928] [c0000011a7157e50] [c00000 ---truncated--- （CVE-2026-45904）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

Linux/Unix ホストには、ベンダーが提供するパッチが利用できない脆弱性の影響を受ける複数のパッケージがインストールされています。

  - Linux カーネルでは、以下の脆弱性が解決されています: powerpc/eeh: fix recursive pci_lock_rescan_remove locking in EEH event handling The recent commit 1010b4c012b0 (powerpc/eeh: Make EEH driver device hotplug safe) restructured the EEH driver to improve synchronization with the PCI hotplug layer. However, it inadvertently moved pci_lock_rescan_remove() outside its intended scope in eeh_handle_normal_event(), leading to broken PCI error reporting and improper EEH event triggering.
    Specifically, eeh_handle_normal_event() acquired pci_lock_rescan_remove() before calling eeh_pe_bus_get(), but eeh_pe_bus_get() itself attempts to acquire the same lock internally, causing nested locking and disrupting normal EEH event handling paths. This patch adds a boolean parameter do_lock to
    _eeh_pe_bus_get(), with two public wrappers: eeh_pe_bus_get() with locking enabled.
    eeh_pe_bus_get_nolock() that skips locking. Callers that already hold pci_lock_rescan_remove() now use eeh_pe_bus_get_nolock() to avoid recursive lock acquisition. Additionally, pci_lock_rescan_remove() calls are restored to the correct positionafter eeh_pe_bus_get() and immediately before iterating affected PEs and devices. This ensures EEH-triggered PCI removes occur under proper bus rescan locking without recursive lock contention. The eeh_pe_loc_get() function has been split into two functions:
    eeh_pe_loc_get(struct eeh_pe *pe) which retrieves the loc for given PE. eeh_pe_loc_get_bus(struct pci_bus
    *bus) which retrieves the location code for given bus. This resolves lockdep warnings such as: <snip> [84.964298] [ T928] ============================================ [ 84.964304] [ T928] WARNING: possible recursive locking detected [ 84.964311] [ T928] 6.18.0-rc3 #51 Not tainted [ 84.964315] [ T928]
    -------------------------------------------- [ 84.964320] [ T928] eehd/928 is trying to acquire lock: [84.964324] [ T928] c000000003b29d58 (pci_rescan_remove_lock){+.+.}-{3:3}, at:
    pci_lock_rescan_remove+0x28/0x40 [ 84.964342] [ T928] but task is already holding lock: [ 84.964347] [T928] c000000003b29d58 (pci_rescan_remove_lock){+.+.}-{3:3}, at: pci_lock_rescan_remove+0x28/0x40 [84.964357] [ T928] other info that might help us debug this: [ 84.964363] [ T928] Possible unsafe locking scenario: [ 84.964367] [ T928] CPU0 [ 84.964370] [ T928] ---- [ 84.964373] [ T928] lock(pci_rescan_remove_lock); [ 84.964378] [ T928] lock(pci_rescan_remove_lock); [ 84.964383] [ T928] *** DEADLOCK *** [ 84.964388] [ T928] May be due to missing lock nesting notation [ 84.964393] [ T928] 1 lock held by eehd/928: [ 84.964397] [ T928] #0: c000000003b29d58 (pci_rescan_remove_lock){+.+.}-{3:3}, at:
    pci_lock_rescan_remove+0x28/0x40 [ 84.964408] [ T928] stack backtrace: [ 84.964414] [ T928] CPU: 2 UID: 0 PID: 928 Comm: eehd Not tainted 6.18.0-rc3 #51 VOLUNTARY [ 84.964417] [ T928] Hardware name: IBM,9080-HEX POWER10 (architected) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_022) hv:phyp pSeries [ 84.964419] [T928] Call Trace: [ 84.964420] [ T928] [c0000011a7157990] [c000000001705de4] dump_stack_lvl+0xc8/0x130 (unreliable) [ 84.964424] [ T928] [c0000011a71579d0] [c0000000002f66e0] print_deadlock_bug+0x430/0x440 [84.964428] [ T928] [c0000011a7157a70] [c0000000002fd0c0] __lock_acquire+0x1530/0x2d80 [ 84.964431] [ T928] [c0000011a7157ba0] [c0000000002fea54] lock_acquire+0x144/0x410 [ 84.964433] [ T928] [c0000011a7157cb0] [c0000011a7157cb0] __mutex_lock+0xf4/0x1050 [ 84.964436] [ T928] [c0000011a7157e00] [c000000000de21d8] pci_lock_rescan_remove+0x28/0x40 [ 84.964439] [ T928] [c0000011a7157e20] [c00000000004ed98] eeh_pe_bus_get+0x48/0xc0 [ 84.964442] [ T928] [c0000011a7157e50] [c00000 ---truncated--- (CVE-2026-45904)

Nessus は、ベンダーによって報告されたパッケージの存在に依存していることに注意してください。

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - In the Linux kernel, the following vulnerability has been resolved: powerpc/eeh: fix recursive     pci_lock_rescan_remove locking in EEH event handling The recent commit 1010b4c012b0 (powerpc/eeh: Make     EEH driver device hotplug safe) restructured the EEH driver to improve synchronization with the PCI     hotplug layer. However, it inadvertently moved pci_lock_rescan_remove() outside its intended scope in     eeh_handle_normal_event(), leading to broken PCI error reporting and improper EEH event triggering.
    Specifically, eeh_handle_normal_event() acquired pci_lock_rescan_remove() before calling eeh_pe_bus_get(),     but eeh_pe_bus_get() itself attempts to acquire the same lock internally, causing nested locking and     disrupting normal EEH event handling paths. This patch adds a boolean parameter do_lock to
    _eeh_pe_bus_get(), with two public wrappers: eeh_pe_bus_get() with locking enabled.
    eeh_pe_bus_get_nolock() that skips locking. Callers that already hold pci_lock_rescan_remove() now use     eeh_pe_bus_get_nolock() to avoid recursive lock acquisition. Additionally, pci_lock_rescan_remove() calls     are restored to the correct positionafter eeh_pe_bus_get() and immediately before iterating affected PEs     and devices. This ensures EEH-triggered PCI removes occur under proper bus rescan locking without     recursive lock contention. The eeh_pe_loc_get() function has been split into two functions:
    eeh_pe_loc_get(struct eeh_pe *pe) which retrieves the loc for given PE. eeh_pe_loc_get_bus(struct pci_bus
    *bus) which retrieves the location code for given bus. This resolves lockdep warnings such as: <snip> [     84.964298] [ T928] ============================================ [ 84.964304] [ T928] WARNING: possible     recursive locking detected [ 84.964311] [ T928] 6.18.0-rc3 #51 Not tainted [ 84.964315] [ T928]
    -------------------------------------------- [ 84.964320] [ T928] eehd/928 is trying to acquire lock: [     84.964324] [ T928] c000000003b29d58 (pci_rescan_remove_lock){+.+.}-{3:3}, at:
    pci_lock_rescan_remove+0x28/0x40 [ 84.964342] [ T928] but task is already holding lock: [ 84.964347] [     T928] c000000003b29d58 (pci_rescan_remove_lock){+.+.}-{3:3}, at: pci_lock_rescan_remove+0x28/0x40 [     84.964357] [ T928] other info that might help us debug this: [ 84.964363] [ T928] Possible unsafe locking     scenario: [ 84.964367] [ T928] CPU0 [ 84.964370] [ T928] ---- [ 84.964373] [ T928]     lock(pci_rescan_remove_lock); [ 84.964378] [ T928] lock(pci_rescan_remove_lock); [ 84.964383] [ T928] ***     DEADLOCK *** [ 84.964388] [ T928] May be due to missing lock nesting notation [ 84.964393] [ T928] 1 lock     held by eehd/928: [ 84.964397] [ T928] #0: c000000003b29d58 (pci_rescan_remove_lock){+.+.}-{3:3}, at:
    pci_lock_rescan_remove+0x28/0x40 [ 84.964408] [ T928] stack backtrace: [ 84.964414] [ T928] CPU: 2 UID: 0     PID: 928 Comm: eehd Not tainted 6.18.0-rc3 #51 VOLUNTARY [ 84.964417] [ T928] Hardware name: IBM,9080-HEX     POWER10 (architected) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_022) hv:phyp pSeries [ 84.964419] [     T928] Call Trace: [ 84.964420] [ T928] [c0000011a7157990] [c000000001705de4] dump_stack_lvl+0xc8/0x130     (unreliable) [ 84.964424] [ T928] [c0000011a71579d0] [c0000000002f66e0] print_deadlock_bug+0x430/0x440 [     84.964428] [ T928] [c0000011a7157a70] [c0000000002fd0c0] __lock_acquire+0x1530/0x2d80 [ 84.964431] [ T928]     [c0000011a7157ba0] [c0000000002fea54] lock_acquire+0x144/0x410 [ 84.964433] [ T928] [c0000011a7157cb0]     [c0000011a7157cb0] __mutex_lock+0xf4/0x1050 [ 84.964436] [ T928] [c0000011a7157e00] [c000000000de21d8]     pci_lock_rescan_remove+0x28/0x40 [ 84.964439] [ T928] [c0000011a7157e20] [c00000000004ed98]     eeh_pe_bus_get+0x48/0xc0 [ 84.964442] [ T928] [c0000011a7157e50] [c00000 ---truncated--- (CVE-2026-45904)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
317133	Linux Distros 未修补的漏洞：CVE-2026-45904	Nessus	Misc.	2026/5/27	2026/5/30	medium
317133	Linux Distros 未修補的弱點：CVE-2026-45904	Nessus	Misc.	2026/5/27	2026/5/30	medium
317133	Linux Distros のパッチ未適用の脆弱性: CVE-2026-45904	Nessus	Misc.	2026/5/27	2026/5/30	medium
317133	Linux Distros Unpatched Vulnerability : CVE-2026-45904	Nessus	Misc.	2026/5/27	2026/5/30	medium

检测

插件搜索

medium

medium

medium

medium