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

  - netfs: fix reference leak Commit 20d72b00ca81 (netfs: Fix the request's work item to not require a ref)     modified netfs_alloc_request() to initialize the reference counter to 2 instead of 1. The rationale was     that the requet's work would release the second reference after completion (via     netfs_{read,write}_collection_worker()). That works most of the time if all goes well. However, it leaks     this additional reference if the request is released before the I/O operation has been submitted: the     error code path only decrements the reference counter once and the work item will never be queued because     there will never be a completion. This has caused outages of our whole server cluster today because tasks     were blocked in netfs_wait_for_outstanding_io(), leading to deadlocks in Ceph (another bug that I will     address soon in another patch). This was caused by a netfs_pgpriv2_begin_copy_to_cache() call which failed     in fscache_begin_write_operation(). The leaked netfs_io_request was never completed, leaving     `netfs_inode.io_count` with a positive value forever. All of this is super-fragile code. Finding out which     code paths will lead to an eventual completion and which do not is hard to see: - Some functions like     netfs_create_write_req() allocate a request, but will never submit any I/O. -     netfs_unbuffered_read_iter_locked() calls netfs_unbuffered_read() and then netfs_put_request(); however,     netfs_unbuffered_read() can also fail early before submitting the I/O request, therefore another     netfs_put_request() call must be added there. A rule of thumb is that functions that return a     `netfs_io_request` do not submit I/O, and all of their callers must be checked. For my taste, the whole     netfs code needs an overhaul to make reference counting easier to understand and less fragile & obscure.
    But to fix this bug here and now and produce a patch that is adequate for a stable backport, I tried a     minimal approach that quickly frees the request object upon early failure. I decided against adding a     second netfs_put_request() each time because that would cause code duplication which obscures the code     further. Instead, I added the function netfs_put_failed_request() which frees such a failed request     synchronously under the assumption that the reference count is exactly 2 (as initially set by     netfs_alloc_request() and never touched), verified by a WARN_ON_ONCE(). It then deinitializes the request     object (without going through the cleanup_work indirection) and frees the allocation (with RCU     protection to protect against concurrent access by netfs_requests_seq_start()). All code paths that fail     early have been changed to call netfs_put_failed_request() instead of netfs_put_request(). Additionally, I     have added a netfs_put_request() call to netfs_unbuffered_read() as explained above because the     netfs_put_failed_request() approach does not work there. (CVE-2025-40007)

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

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

  - netfs参照漏洩を修正します。コミット 20d72b00ca81netfsリクエストの作業項目を修正し、参照を必要としないようにします。netfs_alloc_request() が修正され、参照カウンターが 1 ではなく 2 に初期化されました。正当な理由は、リクエストの作業が 2 番目の参照の後に 2 番目の参照をリリースすることです。 netfs_{read,write}_collection_worker() 経由で完了します。すべてが問題なく、ほとんどの場合、これは有効です。ただし、I/O操作が送信される前にリクエストがリリースされた場合、この追加参照が漏えいします。エラーコードパスは参照カウンターを一度デクリメントするだけで、完了しないため、作業項目は決してキューに入れられません。これは、タスクが netfs_wait_for_outstanding_io() でブロックされていたため、サーバークラスター全体の停止を引き起こし、Ceph でのデッドロックを引き起こしました (別のパッチで間もなく対処する別のバグ)。これは、fscache_begin_write_operation() で失敗した netfs_pgpriv2_begin_copy_to_cache() 呼び出しによって引き起こされました。漏洩した netfs_io_request は決して完了せず、「netfs_inode.io_count」を永久に正の値のままにします。これはすべて、非常に脆弱なコードです。最終的な完了につながるコードパスと、確認するのが困難なコードパスを見つけます。 - netfs_create_write_req() のような一部の関数は、リクエストを割り当てますが、I/O を送信することはありません。 - netfs_unbuffered_read_iter_locked() は netfs_unbuffered_read() を呼び出してから、netfs_put_request() を呼び出します。ただし、netfs_unbuffered_read() も I/O リクエストを送信する前に早期に失敗する可能性があるため、別の netfs_put_request() 呼び出しをそこに追加する必要があります。既定では、「netfs_io_request」を返す関数は I/O を送信せず、その呼び出し元はすべてチェックされる必要があります。参照カウントをより簡単に理解できるように、脆弱性や難読性を軽減するために、 netfs コード全体にオーバーホールが必要です。
    しかし、このバグを修正し、安定版stableバックポートに十分なパッチを生成するために、初期の失敗時にリクエストオブジェクトを素早く解放する最低限のアプローチを試みました。2 番目の netfs_put_request() を毎回追加しないことに決定しました。これは、コードの重複が発生してコードがさらに複雑化する可能性があるためです。代わりに、参照カウントが正確に 2 netfs_alloc_request() によって最初に設定され、決してタッチされない、WARN_ON_ONCE() によって検証される、失敗したリクエストを同期的に解放する netfs_put_failed_request() 関数を追加しました。次に、リクエストオブジェクトを初期化せず(cleanup_work 間接参照を通過しない)、割り当てを解放します(netfs_requests_seq_start() による同時アクセスに対する保護のための RCU 保護付き)。早期に失敗するすべてのコードパスは、netfs_put_request() の代わりに netfs_put_failed_request() を呼び出すように変更されました。さらに、そこでは netfs_put_failed_request() アプローチが機能しないため、上記で説明したように、netfs_put_request() を netfs_unbuffered_read() に追加しました。CVE-2025-40007

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

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

  - netfs修复引用泄漏 Commit 20d72b00ca81netfs修复请求的工作项目以便不需要 ref修改 netfs_alloc_request() 以将引用计数器初始化为 2 而不是 1。其基本原理是请求的工作会在完成通过 netfs_{read,write}_collection_worker()。如果一切顺利的话这在大多数情况下是有效的。但是如果在提交 I/O 操作之前释放请求则会泄漏此额外的引用错误代码路径仅使引用计数器减少一次且工作项目永远不会排队因为永远不会有完成。今天这已造成整个服务器群集中断因为 netfs_wait_for_outstanding_io() 中的任务被阻断进而导致 Ceph 中发生死锁这是我很快将在另一个修补程序中解决的另一个缺陷。这是由 fscache_begin_write_operation() 中失败的 netfs_pgpriv2_begin_copy_to_cache() 调用造成的。被泄露的 netfs_io_request 从未完成导致“netfs_inode.io_count”始终为正值。所有这些都是超级漏洞代码。发现哪些代码路径将导致最终完成哪些不会导致最终完成并非易事 - netfs_create_write_req() 等某些函数会分配请求但始终不会提交任何 I/O。 - netfs_unbuffered_read_iter_locked() 调用 netfs_unbuffered_read()然后调用 netfs_put_request()但是netfs_unbuffered_read() 也可能在提交 I/O 请求之前过早失败因此必须在其中添加另一个 netfs_put_request() 调用。根据经验，返回“netfs_io_request”的函数不会提交 I/O，并且必须检查其所有调用程序。就我个人而言需要对整个 netfs 代码进行彻底检查以便使引用计数更容易理解、更稳定和更隐蔽。
    但是为了立即修复此缺陷并生成足以稳定向后移植的修补程序我尝试了在早期失败时快速释放请求对象的最小方法。我决定不再每次都添加第二个 netfs_put_request()因为那样会造成代码重复从而进一步掩盖代码。相反我添加了函数 netfs_put_failed_request()其会在假设引用计数正好为 2最初由 netfs_alloc_request() 设置且从未接触过并由 WARN_ON_ONCE() 验证的情况下同步释放此类失败的请求。然后去初始化请求对象不经过 cleanup_work 间接引用并释放分配使用 RCU 保护防止 netfs_requests_seq_start() 进行并发访问。所有提前失败的代码路径已更改为调用 netfs_put_failed_request() 而不是 netfs_put_request()。此外如上所示我已向 netfs_unbuffered_read() 添加了 netfs_put_request() 调用因为 netfs_put_failed_request() 方法在这里不起作用。 (CVE-2025-40007)

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

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

  - netfs修正參照洩漏提交 20d72b00ca81 (netfs修正要求的工作項目使其不需要 ref) 修改了 netfs_alloc_request()以將參照計數器初始化為 2 而非 1。基本原理是 reket 的工作會在 之後釋放第二個參照完成 (透過 netfs_{read,write}_collection_worker())。如果一切順利，這在大多數情況下都可以使用。但是如果在提交 I/O 作業之前釋放要求就會洩漏這個額外的參照錯誤程式碼路徑只會遞減參照計數器一次而且因為永遠不會有完成項目因此永遠不會將工作項目排入佇列。這已造成我們今天的整個伺服器叢集中斷因為工作在 netfs_wait_for_outstanding_io() 中遭到封鎖導致 Ceph 鎖死 (另一個錯誤我稍後會在另一個修補程式中加以解決)。這是由 fscache_begin_write_operation() 中失敗的 netfs_pgpriv2_begin_copy_to_cache() 呼叫所造成。洩漏的 netfs_io_request 從未完成而使 `netfs_inode.io_count` 永遠保持正值。所有這些都是超級脆弱的程式碼。找出哪些程式碼路徑將導致最終完成哪些不會導致完成不難。- 部分函式如 netfs_create_write_req() 會配置要求但永遠不會提交任何 I/O。 - netfs_unbuffered_read_iter_locked() 呼叫 netfs_unbuffered_read()然後呼叫 netfs_put_request()不過netfs_unbuffered_read() 也可能在提交 I/O 要求前提早失敗因此必須在此處新增另一個 netfs_put_request() 呼叫。根據經驗傳回 `netfs_io_request` 的函式不會提交 I/O因此必須檢查其所有呼叫者。依我的喜好需要徹底檢修整個 netfs 程式碼以使參照計數更容易理解且不那麼脆弱和模糊。
    但是為了此時此地修正此錯誤並產生足以進行穩定反向移植的修補程式我嘗試了一種在早期失敗時快速釋放要求物件的最小方法。我決定不每次都新增第二個 netfs_put_request()因為這會造成程式碼重複進而進一步模糊化程式碼。相反我新增了 netfs_put_failed_request() 函式該函式會在參照計數正好是 2 (最初由 netfs_alloc_request() 設定且從未動過)且由 WARN_ON_ONCE() 驗證的 假設下同步釋放此類失敗的要求。然後它會取消初始化要求物件 (不經過 cleanup_work 間接取值) 並釋放配置 (使用 RCU 保護防止 netfs_requests_seq_start() 進行的並行存取)。所有提早失敗的程式碼路徑皆已變更為呼叫 netfs_put_failed_request()而非 netfs_put_request()。此外我已如上所述將 netfs_put_request() 呼叫新增至 netfs_unbuffered_read()因為 netfs_put_failed_request() 方法在該處無法運作。 (CVE-2025-40007)

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

ID	Name	Product	Family	Published	Updated	Severity
271665	Linux Distros Unpatched Vulnerability : CVE-2025-40007	Nessus	Misc.	10/27/2025	10/27/2025	high
271665	Linux Distros のパッチ未適用の脆弱性: CVE-2025-40007	Nessus	Misc.	10/27/2025	10/27/2025	high
271665	Linux Distros 未修补的漏洞：CVE-2025-40007	Nessus	Misc.	10/27/2025	10/27/2025	high
271665	Linux Distros 未修補的弱點：CVE-2025-40007	Nessus	Misc.	10/27/2025	10/27/2025	high

Detections

Analytics

Plugins Search

high

high

high

high