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

  - fs：修正巢狀備份檔的使用者路徑 backing_file_open（） 會從 user_file->f_path 派生要儲存在新備份檔中的路徑。當 user_file 本身是備份檔案時，這是不正確的，這是嵌套堆疊檔案系統的情況，例如 overlayfs 掛載，其中一個 overlayfs 的下限目錄是另一個 overlayfs 的合併目錄。由於提交 def3ae83da02 （fs：在後備檔案中儲存真實路徑而不是假路徑 f_path），因此後備檔案的f_path保留中間層的真實路徑，而不是使用者開啟的路徑。提交 924577e4f6ca （ovl：修正巢狀備份檔案路徑） 透過從 ovl_open_realfile（） 傳遞 file_user_path（） 來修正此類配置的此問題。不過，請提交 6af36aeb147a （lsm：
    新增 backing_file LSM 鉤子）將 backing_file_open（） 的第一個引數從使用者路徑改回使用者檔案，並再次從 user_file->f_path 派生路徑，靜默地重新引入問題。因此，透過巢狀 overlayfs 對應的檔案會在 /proc/<pid>/maps 和 perf/ftrace mmap 記錄中顯示錯誤的路徑。例如，使用兩個巢狀 overlayfs 掛載： mkdir -p /ovl/{lower，upper，work，merged} /ovl/nested echo hello > /ovl/lower/foo mount -t overlay overlay \ -o lowerdir=/ovl/lower，upperdir=/ovl/upper，workdir=/ovl/work \ /ovl/merged # 當 upperdir 不存在時，至少需要兩個 lowerdir mount -t overlay overlay \ -o lowerdir=/ovl/merged：/ovl/lower /ovl/nested mapping /ovl/nested/foo 顯示中斷連線的路徑，而不是使用者路徑： # readlink /proc/self/fd/3 /ovl/nested/foo # grep foo /proc/self/maps 7f6e2c100000-7f6e2c101000 r--s 00000000 00:24 15813027 /foo 虛假路徑源自中間備份檔的f_path，其掛載是 d_path（） 無法解析的私有複製。使用 file_user_path（） 修正此問題，該路徑會傳回備份檔案的最外層使用者可見路徑，並針對一般檔案回歸 &user_file->f_path。這還原了 overlayfs 的提交 924577e4f6ca （ovl： 修正巢狀備份檔案路徑） 的行為，也修正了其他 backing_file_open（） 呼叫端、fuse passthrough 和 erofs ishare 的相同問題，當其使用者檔案本身是備份檔案時。backing_tmpfile_open（） 具有相同的模式，但不受影響：
    它僅由上層的 ovl_create_tmpfile（） 調用，而另一個 overlayfs 被 ovl_mount_dir_check（） 中的DCACHE_OP_REAL檢查作為上層拒絕，因此其user_file永遠不能是備份檔。（CVE-2026-89768）

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

偵測

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

low Nessus Plugin ID 345263

版本 1.1