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

  - vfsumount で切断された dentry が漏洩されません。キャッシュされていない inode でユーザーが open_by_handle_at() を呼び出すとき、切断された dentry がそれに対して作成されます。そのような dentry がディレクトリである場合、exportfs_decode_fh_raw() は reconnect_path() を通じて dentry ツリーにこの dentry を接続しようとします。
    いくつかの理由 (破損した fs や名前の変更との競合など) で、reconnect_one() の lookup_one_unlocked() への呼び出しが、再接続しようとしている dentry を見つけることができず、その代わりに親の下に新しい dentry が作成される可能性があります。現在は、親が切断されている可能性がありますが、この dentry は切断済みとしてマークされません少なくともこの不一致は、fs が破損しており、 .. が実際の親ディレクトリを指していないために発生します。これは切断されたフラグに不整合を生じさせますが、AFAICS ではほとんど無害でした。少なくともコミット f1ee616214cb までVFSd_anon で切断された dentry を保持しないことで、sb->s_anon リストへのほとんどの切断された dentry の追加を削除しました。このため、このコミットの後で、切断された dentry のクリーンアップは、dput() が即座にそのような dentry を再要求するという事実に暗黙のうちに依存します。ただし、上記のシナリオのように、一部のリーフ dentry が切断済みとしてマークされていない場合、再利用は発生せず dentry が漏洩します。メモリ再要求は、最終的にはそれらを再要求できますが、そうでなければメモリ内に留まります。また、umount が最初に発生した場合、アンマウントバグの後に悪名が高い Busy inode が見つかりました。切断された親の下で作成されたすべての dentry が、切断済みとしてもマークされるようにします。CVE-2025-40105

Nessus は、ベンダーによって報告されたパッケージの存在に依存していることに注意してください。

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

  - vfs卸載時不洩漏已中斷的 dentry。當使用者在未快取的某些 inode 上呼叫 open_by_handle_at() 時我們會為其建立已中斷的 dentry。如果此類 dentry 是目錄則 exportfs_decode_fh_raw() 會嘗試透過 reconnect_path() 將此 dentry 連線至 dentry 樹狀結構。
    由於多種原因 (例如損毀的 fs 或爭用重新命名)可能會發生 reconnect_one() 中的 lookup_one_unlocked() 呼叫找不到我們嘗試重新連線的 dentry而是在父項下建立新的 dentry。現在雖然父項仍可能中斷連線但現在此 dentry 將不會標記為中斷連線 (至少在發生此不一致的情況下因為 fs 已損毀且 .. 未指向真正的父目錄)。這會在中斷的旗標中造成不一致但 AFAICS 旗標大多是無害的。至少在認可 f1ee616214cb (VFS不保留 d_anon 上中斷連線的 dentry) 之前都會移除將大部分中斷連線的 dentry 新增至 sb->s_anon 清單的情況。因此在此提交後清理中斷的 dentry 會隱含依賴 dput() 會立即回收此類 dentry 的事實。但是當某些分葉 dentry 未標記為中斷連線時 (如在上述狀況中)則不會發生回收並且 dentry 會遭到洩漏。記憶體回收最終會回收它們但否則它們會保留在記憶體中。如果先卸載我們會命中著名的卸載後忙碌 inodes 錯誤。請確認在中斷連線之父項之下建立的所有 dentry 也都標示為已中斷連線。 (CVE-2025-40105)

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

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - vfs: Don't leak disconnected dentries on umount When user calls open_by_handle_at() on some inode that is     not cached, we will create disconnected dentry for it. If such dentry is a directory,     exportfs_decode_fh_raw() will then try to connect this dentry to the dentry tree through reconnect_path().
    It may happen for various reasons (such as corrupted fs or race with rename) that the call to     lookup_one_unlocked() in reconnect_one() will fail to find the dentry we are trying to reconnect and     instead create a new dentry under the parent. Now this dentry will not be marked as disconnected although     the parent still may well be disconnected (at least in case this inconsistency happened because the fs is     corrupted and .. doesn't point to the real parent directory). This creates inconsistency in disconnected     flags but AFAICS it was mostly harmless. At least until commit f1ee616214cb (VFS: don't keep disconnected     dentries on d_anon) which removed adding of most disconnected dentries to sb->s_anon list. Thus after     this commit cleanup of disconnected dentries implicitely relies on the fact that dput() will immediately     reclaim such dentries. However when some leaf dentry isn't marked as disconnected, as in the scenario     described above, the reclaim doesn't happen and the dentries are leaked. Memory reclaim can eventually     reclaim them but otherwise they stay in memory and if umount comes first, we hit infamous Busy inodes     after unmount bug. Make sure all dentries created under a disconnected parent are marked as disconnected     as well. (CVE-2025-40105)

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

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

  - vfs卸载时不泄漏断开的 dentry 当用户在未缓存的某些 inode 上调用 open_by_handle_at() 时我们将为其创建断开的 dentry。如果此类 dentry 是目录exportfs_decode_fh_raw() 随后会尝试通过 reconnect_path() 连接此 dentry 与 dentry 树。
    可能会因多种原因如 fs 损毁或重命名争用对 reconnect_one() 中 lookup_one_unlocked() 的调用无法找到我们尝试重新连接的 dentry而是在父项下创建新 dentry。现在此 dentry 不会被标记为已断开连接尽管父项可能仍会断开连接至少在由于 fs 已损坏且 .. 未指向真正的父目录而发生此不一致的情况下是这样。这会造成断开连接标记中的不一致但对 AFAICS 基本无害。至少在提交 f1ee616214cb VFS不在 d_anon 上保持断开连接的 dentry之前此状态删除了大多数断开连接的 dentry 到 sb->s_anon 列表的添加。因此在此提交后断开的 dentry 的清理隐式依赖 dput() 将立即回收此类 dentry。但是当某些叶 dentry 未标记为已断开连接时如上述情况所示则不会发生回收且 dentry 会泄漏。内存回收最终可以回收它们但否则它们会留在内存中并且如果首先发生卸载我们会命中声名远播的忙碌 inode 卸载缺陷。确保在断开连接的父项下创建的所有 dentry 也被标记为断开连接。 (CVE-2025-40105)

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

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
272061	Linux Distros のパッチ未適用の脆弱性: CVE-2025-40105	Nessus	Misc.	2025/10/30	2025/11/3	medium
272061	Linux Distros 未修補的弱點：CVE-2025-40105	Nessus	Misc.	2025/10/30	2025/11/3	medium
272061	Linux Distros Unpatched Vulnerability : CVE-2025-40105	Nessus	Misc.	2025/10/30	2025/11/3	medium
272061	Linux Distros 未修补的漏洞：CVE-2025-40105	Nessus	Misc.	2025/10/30	2025/11/3	medium

检测

插件搜索

medium

medium

medium

medium