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

  - mm/huge_memory：將 PMD 髒位傳輸到 Zap 上的對開本 zap_huge_pmd_folio（） 會將 PMD 年輕位元傳播到檔案盒的對開本，但不會傳播髒位。pte 路徑確實在 zap_present_folio_ptes（） 中傳播它，在 __split_huge_pmd_locked（） 中 pmd 拆分路徑也是如此。對於大多數檔案對應來說，遺漏是無害的，因為寫入共用檔案對應會經過 page_mkwrite（），這會弄髒對開本。tmpfs 則不同：它沒有 page_mkwrite（），而 vma_wants_writenotify（） 對它來說是 false，因此MAP_SHARED tmpfs 映射上的 *讀取* 錯誤會透過 do_read_fault（） 安裝可寫入的 PMD。
    do_read_fault（） 不會呼叫 fault_dirty_shared_page（），因此透過該映射的後續儲存區只會在 pmd 中設定硬體髒位，並且永遠不會呼叫 folio_mark_dirty（）。錯誤分配的 shmem 作品集被標記為 uptodate，但不是髒的（請參閱 shmem_get_folio_gfp（）） 中的 clear： 區塊），因此根本不會設定PG_dirty。當進程終止時，取消映射這樣的對開本 - munmap（） 或 exit_mmap（） - 然後丟失它寫入的唯一記錄，因為 zap_huge_pmd（） 會刪除 pmd 而不傳輸髒位。
    之後回收會看到一個乾淨的 shmem 對開本：shrink_folio_list（） 中的整個換出區塊都在 if （folio_test_dirty（folio）） 內，因此跳過 pageout（） 並且對開本落入 __remove_mapping（） 中。在那裡，folio_is_file_lru（） 對於交換式作品集來說是 false，因此不會建立影子項目，並且
    __filemap_remove_folio（對開本，NULL） 只會清空i_pages槽。資料會釋放，而從未寫入交換，而該索引上的下一個錯誤會傳回新歸零的對開本。對於在取消映射中將狀態保持在MAP_SHARED tmpfs 區段中的任何進程來說，這是無訊息資料遺失 - 例如，透過 /dev/shm 從一個處理程序世代傳遞到下一個處理程序世代的快取。它要求對開本進行 PMD 映射，因此它僅在啟用 shmem THP 後才會顯示（這就是我們在 Meta 車隊中所做的並開始注意到崩潰）;當 THP 關閉時，PTE 路徑會正確傳輸髒位元。它也僅在啟用交換時才可見，因為在沒有交換裝置的情況下，shmem 作品集（位於匿名 LRU 上）根本不會被回收掃描，因此乾淨的作品集永遠不會被丟棄。在具有 tmpfs 掛載 huge=within_size的 x86_64 上重現：讀取錯誤 2MB 支援的區域，透過產生的映射寫入已知模式，munmap，強制回收 cgroup，然後重新映射並回讀。如果沒有此修補程式，區域會以零讀取，而 vmstat 會顯示 zswpout 0 - 資料已捨棄，而非交換。使用此修補程式後，區域可以正確讀取，並且頁面會如預期般交換。使用 huge=never，或當第一次接觸是寫入時，測試會以任一方式通過。（CVE-2026-89987）

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

偵測

Linux Distros 未修補弱點：CVE-2026-89987

medium Nessus Plugin ID 346730

版本 1.12