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

  - KVM： arm64： vgic： 修正 LPI 發行與重新登錄之間的爭用 修正遞減 LPI 參照計數與從 LPI xarray 逐出該結構之間的潛在爭用。LPI 結構會維護在 VGIC LPI xarray （dist->lpi_xa） 中。當 LPI 結構的參照計數降至零時，vgic_release_lpi_locked（） 會從 xarray 中移除該結構，並在 xarray 鎖定下釋放它。
    不過，LPI 的發行可能會透過另一個 CPU 上的 vgic_add_lpi（） 與具有相同 INTID 的並行 LPI 重新註冊競爭，因為參照計數下降和 xarray 逐出不會在單一原子步驟中執行。例如，如果客體發出 DISCARD，而 LPI 仍從 vCPU 的作用中擱置清單 （ap_list） 參照，並且透過 MAPTI 重新映射相同的 INTID，則可能會發生這種情況。特別是，vgic_release_lpi_locked（） 是從兩個不同的路徑呼叫的：透過 vgic_put_irq（） 的直接發布，以及透過 vgic_release_deleted_lpis（） 的延遲發布。在直接發行期間，此問題可能會導致從 xarray 中刪除新註冊的 LPI： CPU0 （釋放 LPI） CPU1 （新增 LPI） ==================== ===================== vgic_put_irq（） __vgic_put_irq（） refcount_dec_and_test（） vgic_add_lpi（） xa_lock_irqsave（） old_irq = xa_load（..， intid） vgic_try_get_irq_ref（old_irq） == false 插入新的 IRQ -->
    __xa_store（..， intid， ..） xa_unlock_irqrestore（） xa_lock_irqsave（）;vgic_release_lpi_locked（）
    __xa_erase（..， irq->intid） <-- 錯誤：新的 IRQ 被刪除 kfree_rcu（old_irq） 在延遲發布路徑期間，舊的 IRQ 可能會洩漏： CPU0 （釋放 LPI） CPU1 （新增 LPI） ==================== ===================== vgic_put_irq_norelease（） __vgic_put_irq（） refcount_dec_and_test（） irq->pending_release = true vgic_add_lpi（） xa_lock_irqsave（） old_irq = xa_load（..， intid） vgic_try_get_irq_ref（oldirq） == false 錯誤：舊的 IRQ 被覆寫 --> __xa_store（..， intid， ..） xa_unlock_irqrestore（） vgic_release_deleted_lpis（） xa_lock_irqsave（） xa_for_each（） { .. } <-- pending_release = true 的舊 IRQ 已經消失，因此無法釋放 要修復直接釋放路徑，請將參照計數刪除移動到 xarray 鎖定內， 確保 vgic_add_lpi（） 永遠不會遇到即將發布的 LPI。在延遲釋放路徑中，參照計數卸除必須在原始微調鎖定下發生，因此無法抓取 xarray 鎖定，而且相同的解決方案不起作用。相反地，更新 vgic_add_lpi（），這樣如果它從 xarray 中逐出 LPI，它就會承擔釋放它的責任。因此，在延遲發行捨棄參照計數之後，LPI 現在可能會同時釋放，因此存取 pending_release 欄位不再安全，免於釋放後使用。刪除旗標的所有使用，並更新 vgic_release_deleted_lpis（） 以純粹根據孤立的 LPI 的參照計數來識別孤立的 LPI。（CVE-2026-74568）

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

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

  - KVM：arm64：vgic：修复 LPI 释放和重新注册之间的争用 修复递减 LPI 的引用计数与从 LPI xarray 中逐出该结构之间可能的争用。LPI 结构在 VGIC LPI xarray （dist->lpi_xa） 中维护。当 LPI 结构的引用计数降至零时，vgic_release_lpi_locked（） 将该结构从 xarray 中删除并在 xarray 锁定下释放。
    但是，LPI 的发布可能与通过另一个 CPU 上的 vgic_add_lpi（） 使用相同 INTID 的并行 LPI 重新注册争用，因为引用计数终止和 xarray 逐出不是在单个原子步骤中执行的。例如，如果客户机发出 DISCARD 而 LPI 仍从 vCPU 的活动挂起列表 （ap_list） 中引用，并且通过 MAPPI 重新映射了相同的 INTID。具体而言，vgic_release_lpi_locked（） 是从两个不同的路径调用的：通过 vgic_put_irq（） 的直接释放，以及通过 vgic_release_deleted_lpis（） 的延迟释放。在直接释放期间，此问题可导致从 xarray 中删除新注册的 LPI： CPU0（释放 LPI） CPU1（添加新 LPI） ==================== ===================== vgic_put_irq（） __vgic_put_irq（） refcount_dec_and_test（） vgic_add_lpi（） xa_lock_irqsave（） old_irq = xa_load（..， intid） vgic_try_get_irq_ref（old_irq） == false inserted new IRQ -->
    __xa_store（..， intid， ..） xa_unlock_irqrestore（） xa_lock_irqsave（）;vgic_release_lpi_locked（）
    __xa_erase（..， irq->intid） <-- 缺陷：新 IRQ 被删除 kfree_rcu（old_irq） 在延迟释放路径期间，旧 IRQ 可被泄漏： CPU0（释放 LPI） CPU1（添加新 LPI） ==================== ===================== vgic_put_irq_norelease（） __vgic_put_irq（） refcount_dec_and_test（） irq->pending_release = true vgic_add_lpi（） xa_lock_irqsave（） old_irq = xa_load（..， intid） vgic_try_get_irq_ref（oldirq） == false BUG：旧 IRQ 被覆盖 --> __xa_store（..， intid， ..） xa_unlock_irqrestore（） vgic_release_deleted_lpis（） xa_lock_irqsave（） xa_for_each（） { .. } <-- pending_release = true 的旧 IRQ 已消失，因此无法释放 要修复直接释放路径，请将引用计数终止移动到 xarray 锁定内部， 确保 vgic_add_lpi（） 永远不会遇到即将发布的 LPI。在延迟释放路径中，refcount 终止必须在原始旋转锁下发生，因此无法抓取 xarray 锁定，并且相同的解决方案无效。而是更新 vgic_add_lpi（），以便当它从 xarray 中逐出 LPI 时，它会承担释放它的责任。因此，延迟发布丢弃 refcount 后，LPI 现在可同时释放，因此访问 pending_release 字段不再安全免受释放后使用的影响。删除该标记的所有使用，并更新 vgic_release_deleted_lpis（） 以纯粹根据其引用计数识别孤立的 LPI。（CVE-2026-74568）

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

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

  - KVM:arm64:vgic:LPI リリースと再登録の間の競合を修正します LPI の参照カウントの減少と、LPI xarray からのその構造体の退去の間の潜在的な競合を修正します。LPI 構造は、VGIC LPI xarray(dist->lpi_xa)で維持されます。LPI 構造体の参照カウントがゼロになると、vgic_release_lpi_locked() は xarray からその構造体を削除し、それを xarray ロック下で解放します。
    ただし、LPI のリリースは、別の CPU 上の vgic_add_lpi() を介して同じ INTID を介した同時 LPI 再登録と競合する可能性があります。これは、参照カウントのドロップと xarray の削除が単一のアトミックステップで実行されないためです。これは例えば、LPIがvCPUのアクティブペンディングリスト(ap_list)からまだ参照されている間にゲストがDISCARDを発行し、同じINTIDがMAPTIを介して再マッピングされた場合などに発生する可能性があります。特に、vgic_release_lpi_locked() は、vgic_put_irq() による直接リリースと vgic_release_deleted_lpis() による遅延リリースの 2 つの異なるパスから呼び出されます。直接リリース中に、この問題により、新しく登録された LPI が xarray から削除される可能性があります: CPU0(LPI をリリース) CPU1(新しい LPI を追加) ==================== ===================== vgic_put_irq() __vgic_put_irq() refcount_dec_and_test() vgic_add_lpi() xa_lock_irqsave() old_irq = xa_load(.., intid) vgic_try_get_irq_ref(old_irq) == false 新しい IRQ が挿入されました -->
    __xa_store(.., intid, ..) xa_unlock_irqrestore() xa_lock_irqsave();vgic_release_lpi_locked()
    __xa_erase(.., irq->intid) <-- BUG:新しい IRQ が消去されます kfree_rcu(old_irq) 遅延リリースパス中に、古い IRQ が漏洩する可能性があります: CPU0(LPI のリリース) CPU1 (新しい LPI の追加) ==================== ===================== vgic_put_irq_norelease() __vgic_put_irq() refcount_dec_and_test() irq->pending_release = true vgic_add_lpi() xa_lock_irqsave() old_irq = xa_load(.., intid) vgic_try_get_irq_ref(oldirq) == false BUG: 古い IRQ が上書きされます --> __xa_store(.., intid, ..) xa_unlock_irqrestore() vgic_release_deleted_lpis() xa_lock_irqsave() xa_for_each() { .. } <-- pending_release = true の古い IRQ はなくなっているため、リリースできません 直接リリースパスを修正するには、参照カウントドロップを xarray ロックの内側に移動し、 vgic_add_lpi() がリリース予定の LPI に遭遇しないようにします。遅延リリースパスでは、refcount のドロップは raw スピンロックの下で発生する必要があるため、xarray ロックをつかむことができず、同じソリューションが機能しません。代わりに、vgic_add_lpi() を更新して、xarray から LPI を退去させた場合、それを解放する責任を引き受けるようにします。結果として、遅延リリースで refcount がドロップされた後に LPI が同時に解放されるようになったため、pending_release フィールドへのアクセスは use-after-free から安全ではなくなりました。フラグの使用をすべて削除し、vgic_release_deleted_lpis() を更新して、純粋に refcount に基づいて孤立した LPI を特定します。(CVE-2026-74568)

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: KVM: arm64: vgic: Fix race between LPI     release and re-registration Fix a potential race between decrementing an LPI's reference count and     evicting that structure from the LPI xarray. LPI structures are maintained in the VGIC LPI xarray     (dist->lpi_xa). When the reference count of an LPI structure drops to zero, vgic_release_lpi_locked()     removes the structure from the xarray and frees it under the xarray lock. However, the release of an LPI     can race with a concurrent LPI re-registration with the same INTID via vgic_add_lpi() on another CPU,     since the reference count drop and the xarray eviction are not performed in a single atomic step. This can     happen e.g. if the guest issues a DISCARD while the LPI is still referenced from a vCPU's active-pending     list (ap_list), and the same INTID is re-mapped via MAPTI. Particularly, vgic_release_lpi_locked() is     called from two distinct paths: direct release via vgic_put_irq(), and deferred release via     vgic_release_deleted_lpis(). During direct release, the issue can result in deleting a newly registered     LPI from the xarray: CPU0 (Releasing LPI) CPU1 (Adding new LPI) ==================== =====================     vgic_put_irq() __vgic_put_irq() refcount_dec_and_test() vgic_add_lpi() xa_lock_irqsave() old_irq =     xa_load(.., intid) vgic_try_get_irq_ref(old_irq) == false new IRQ inserted --> __xa_store(.., intid, ..)     xa_unlock_irqrestore() xa_lock_irqsave(); vgic_release_lpi_locked() __xa_erase(.., irq->intid) <-- BUG:
    new IRQ is erased kfree_rcu(old_irq) During the deferred release path, the old IRQ can be leaked: CPU0     (Releasing LPI) CPU1 (Adding new LPI) ==================== ===================== vgic_put_irq_norelease()
    __vgic_put_irq() refcount_dec_and_test() irq->pending_release = true vgic_add_lpi() xa_lock_irqsave()     old_irq = xa_load(.., intid) vgic_try_get_irq_ref(oldirq) == false BUG: old IRQ overwritten -->
    __xa_store(.., intid, ..) xa_unlock_irqrestore() vgic_release_deleted_lpis() xa_lock_irqsave()     xa_for_each() { .. } <-- old IRQ with pending_release = true is gone, so it cannot be released To fix the     direct release path, move the reference count drop inside the xarray lock, making sure that vgic_add_lpi()     never encounters the to-be-released LPI. In the deferred release path, the refcount drop must happen under     a raw spinlock, so the xarray lock cannot be grabbed, and the same solution does not work. Instead, update     vgic_add_lpi(), so that if it evicts an LPI from the xarray, it takes on the responsibility of freeing it.
    Consequently, an LPI may now be freed concurrently after a deferred release drops the refcount, so     accessing the pending_release field is no longer safe from use-after-free. Delete all uses of the flag,     and update vgic_release_deleted_lpis() to identify orphaned LPIs purely based on their refcount.
    (CVE-2026-74568)

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

ID	名前	製品	ファミリー	公開日	更新日	深刻度
335881	Linux Distros 未修補弱點：CVE-2026-74568	Nessus	Misc.	2026/8/15	2026/11/13	critical
335881	Linux Distros 未修补的漏洞：CVE-2026-74568	Nessus	Misc.	2026/8/15	2026/11/13	critical
335881	Linux Distros のパッチ未適用の脆弱性: CVE-2026-74568	Nessus	Misc.	2026/8/15	2026/11/13	critical
335881	Linux Distros Unpatched Vulnerability : CVE-2026-74568	Nessus	Misc.	2026/8/15	2026/11/13	critical

検出

プラグインの検索

critical

critical

critical

critical