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

  - mm，swap：不释放交换缓存中的休眠槽 交换缓存中具有作品集的插槽在离开缓存时被释放，而不是在其计数下降时被释放。swap_put_entries_cluster（） 遵循该规则。swap_free_hibernation_slot（） 不会，无论 folio 是否位于插槽上，它都会调用 __swap_cluster_free_entries（）。群集预读可以在那里放置一个。它遍历一个原始page_cluster大小的偏移窗口，围绕有故障的条目，休眠槽会传递 __swap_cache_add_check（），因为它不是作品集，其计数不是零。然后释放该槽将清除该作品集下的条目。现在无法从交换表访问该作品集，并且偏移量将返回到分配器。不过，对开本仍在 LRU 上，因此 reclaim 可以稍后拿起它。然后，它从 folio->swap 中移除旧偏移并覆盖此处的表条目，此时该表条目可能属于其他人。此错误可在完全不相关的用户空间应用程序间触发静默内存损坏、进程崩溃或数据不稳定，这通常发生在 uswsusp 准备休眠图像时。我在努力在交换表中为休眠槽提供自己的标记时发现了这一点，我已经与 Kairui 讨论过了这一点。
    （https://lore.kernel.org/linux-mm/abp7aDgYLrxF3Me8@KASONG-MC4/） 据我所知，没有报告，因此没有报告者/关闭者可添加。在释放之前检查缓存的作品集。然后，插槽处于普通状态，只有交换缓存保存它，当作品集离开缓存时，通过下面的回收或稍后的正常回收将其释放。（CVE-2026-89760）

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

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

  - mm， swap：不要釋放交換快取中的休眠插槽 交換快取中具有對開本的插槽會在對開本離開快取時釋放，而不是在其計數下降時釋放。swap_put_entries_cluster（） 遵循該規則。swap_free_hibernation_slot（） 不會，它會呼叫 __swap_cluster_free_entries（），無論對開本是否位於插槽上。叢集預讀可以在那裡放置一個。它會在錯誤項目周圍遍歷原始page_cluster大小的偏移窗口，並且休眠槽會通過 __swap_cache_add_check（），因為它不是對開本，其計數不是零。然後釋放插槽會清除該對開本下的項目。現在無法從交換表存取對開本，而且偏移會回到配置器。不過，對開本仍在 LRU 上，因此回收可以稍後取回它。然後，它從對開本>交換中取出舊的偏移量並覆蓋那裡的表格條目，屆時該表條目可能屬於其他人。此錯誤可能會在完全不相關的使用者空間應用程式中觸發無訊息記憶體損毀、進程當機或資料不穩定 - 通常發生在 uswsusp 準備休眠映像檔時。我在嘗試在交換表中為休眠槽提供自己的標記時發現了這一點，我曾與 Kairui 討論過。
    （https://lore.kernel.org/linux-mm/abp7aDgYLrxF3Me8@KASONG-MC4/） 據我所知，沒有報告，因此沒有報告者/關閉者可添加。釋放前檢查是否有已快取的對開本。然後，插槽會保持只有交換快取保留的正常狀態，並在對開本離開快取時釋放插槽，無論是透過下面的回收還是稍後的正常回收。（CVE-2026-89760）

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

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

  - mm、swap:スワップキャッシュにあるハイバネーションスロットを解放しません。スワップキャッシュにフォリオのあるスロットは、カウントが落ちたときではなく、フォリオがキャッシュを離れるときに解放されます。swap_put_entries_cluster()はそのルールに従います。swap_free_hibernation_slot() は、フォリオがスロットに配置されているかどうかに関係なく、__swap_cluster_free_entries() を呼び出しません。クラスターの事前読み取りは、そこに 1 つを配置できます。これは、障害のあるエントリの周りのオフセットの生page_clusterサイズのウィンドウをウォークし、休止スロットはフォリオではなく、そのカウントがゼロではないため、__swap_cache_add_check()を渡します。スロットを解放すると、そのフォリオの下のエントリがクリアされます。これで、フォリオはスワップテーブルから到達できなくなり、オフセットはアロケーターに戻ります。ただし、フォリオはまだ LRU にあるので、リクレイムは後で受け取ることができます。次に、folio->swap から古いオフセットを取り出し、そこにあるテーブルエントリを上書きします。その時までにそれは他の誰かに属している可能性があります。このバグにより、完全に無関係のユーザー空間アプリケーション間で、サイレントメモリ破損、プロセスクラッシュ、またはデータの不安定性を引き起こす可能性があります。これは通常、uswsusp が休止状態イメージを準備しているときに発生します。これは、スワップテーブルで休眠スロットに独自のマーカーを与える作業中に見つけましたが、これは Kairui と話し合いました。
    (https://lore.kernel.org/linux-mm/abp7aDgYLrxF3Me8@KASONG-MC4/)私の知る限り、レポートはないので、追加する報告者/クローズはありません。解放する前にキャッシュされたフォリオをチェックします。スロットは、スワップキャッシュのみが保持する通常の状態のままになり、以下の回収または後の通常の回収によって、フォリオがキャッシュを離れると解放されます。(CVE-2026-89760)

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: mm, swap: don't free a hibernation     slot that is in the swap cache A slot with a folio in the swap cache is freed when the folio leaves the     cache, not when its count drops. swap_put_entries_cluster() follows that rule.
    swap_free_hibernation_slot() does not, it calls __swap_cluster_free_entries() whether or not a folio sits     on the slot. Cluster readahead can put one there. It walks a raw page_cluster sized window of offsets     around the faulting entry, and a hibernation slot passes __swap_cache_add_check() because it is not a     folio and its count is not zero. Freeing the slot then clears the entry under that folio. The folio is now     unreachable from the swap table, and the offset goes back to the allocator. The folio is still on the LRU     though, so reclaim can pick it up later. It then takes the old offset out of folio->swap and overwrites     the table entry there, which by then may belong to someone else. This bug can trigger silent memory     corruption, process crashes, or data instability across completely unrelated userspace applications -     typically occurring when uswsusp is preparing the hibernation image. I found this while working on giving     hibernation slots their own marker in the swap table, which I had discussed with Kairui.
    (https://lore.kernel.org/linux-mm/abp7aDgYLrxF3Me8@KASONG-MC4/) As far as I know there are no reports, so     there is no Reported-by/Closes to add. Check for a cached folio before freeing. The slot is then left in     the ordinary state where only the swap cache holds it, and it is freed when the folio leaves the cache,     either through the reclaim below or through normal reclaim later. (CVE-2026-89760)

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

ID	名稱	產品	系列	已發布	已更新	嚴重性
345137	Linux Distros 未修补的漏洞：CVE-2026-89760	Nessus	Misc.	2026/9/12	2026/11/13	high
345137	Linux Distros 未修補弱點：CVE-2026-89760	Nessus	Misc.	2026/9/12	2026/11/13	high
345137	Linux Distros のパッチ未適用の脆弱性: CVE-2026-89760	Nessus	Misc.	2026/9/12	2026/11/13	high
345137	Linux Distros Unpatched Vulnerability : CVE-2026-89760	Nessus	Misc.	2026/9/12	2026/11/13	high

偵測

搜尋 Plugin

high

high

high

high