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

  - f2fswhiteout 建立失敗時的 dentry 快取失效 F2FS 可以掛載具有損毀目錄深度值的檔案系統其在運行時間中會被限制為 MAX_DIR_HASH_DEPTH。當在此類目錄上執行 RENAME_WHITEOUT 作業時f2fs_rename 會先執行目錄修改 (更新目標項目和刪除來源項目)然後再嘗試透過 f2fs_add_link 新增 whiteout 項目。如果 f2fs_add_link 因目錄結構損毀而失敗該函式會將錯誤傳回至 VFS但部分目錄修改已提交至磁碟。VFS 假設整個重新命名作業失敗且不會更新 dentry 快取而留下過時對應。在錯誤路徑中VFS 未呼叫 d_move() 來更新 dentry 快取。這導致 new_dentry 仍指向 i_nlink 遞減為零的舊 inode (new_inode)。過時的快取造成後續作業不正確地參照釋出的 inode。這會造成後續作業使用不再符合磁碟上狀態的快取 dentry 資訊。當第二次重新命名以相同的項目為目標時VFS 會嘗試遞減過時 inode (可能已有 i_nlink=0) 上的 i_nlink進而在 drop_nlink() 中觸發警告。範例序列1. 首先重新命名 (RENAME_WHITEOUT)file2 file1 - f2fs 更新磁碟上的 file1 項目 (指向 inode 8) - f2fs 刪除磁碟上的 file2 項目 - f2fs_add_link(whiteout) 失敗 (目錄損毀) - 將錯誤傳回至 VFS - VFS因為錯誤未呼叫 d_move() - VFS 快取仍有 file1 inode 7 (過時!) - inode 7 有 i_nlink=0 (已遞減) 2. 第二次重新命名 file3 file1 - VFS 使用過時快取 file1 inode 7 -嘗試在 inode 7 上進行 drop_nlink (i_nlink 已經是 0) - drop_nlink() 中的警告在白名單建立期間 f2fs_add_link 失敗時明確地使 old_dentry 和 new_dentry 無效。方法是明確地作廢 old_dentry 和 new_dentry。這會強制 VFS 在進行後續作業時從磁碟重新整理即使部分重新命名成功仍可確保快取一致性。Reproducer1. 以損毀的 i_current_depth 掛載 F2FS 影像 2. renameat2(file2, file1, RENAME_WHITEOUT) 3. renameat2(file3, file1, 0) 4. 系統在 drop_nlink() 中觸發警告 (CVE-2025-71069)

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

偵測

Linux Distros 未修補的弱點：CVE-2025-71069

medium Nessus Plugin ID 283642

版本 1.29