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

  - iomap：在 iomap 回呼失敗時釋放對開本批次 對不相關修補程式的 sashiko 審查指出，用於 iomap 零範圍的對開批次機制在幾個錯誤情況下無法釋放批次。如果呼叫 ->iomap_end（） 或 ->iomap_begin（） 失敗，則直接傳回路徑會繞過批次清除。->iomap_end（） 情況目前不是一個實際問題，因為沒有從此路徑傳回錯誤的機制使用者。理論上，->iomap_begin（） 情況是可能的，因為 XFS 可以叫用填充協助程式，並在之後的不同時間點出錯。這讓事情變得微妙複雜，因為 XFS 不會將iomap_flags傳輸到錯誤路徑中的 iomap 資料結構。若要處理這兩個問題，請先確保在任一 fs 回呼的錯誤路徑中叫用清理協助程式。其次，更新協助程式以無條件清除旗標，只要填入批次即可釋放批次。這更清楚地描述了標誌控制 I/O 路徑的目的，而不一定是 fbatch 的狀態，因此也在此周圍添加註釋。（CVE-2026-90384）

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

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

  - iomap：在 iomap 回调失败时发布 folio 批次 对不相关修补程序的 sashiko 审查指出，在一些错误情况下，用于 iomap 零范围的 folio 批处理机制无法释放批次。如果调用 ->iomap_end（） 或 ->iomap_begin（） 失败，则直接返回路径将绕过批量清理。当前不存在 ->iomap_end（） 情况，因为没有机制的用户可从此路径返回错误。理论上可发生 ->iomap_begin（） 情况，因为 XFS 可调用填充帮助程序，并在此后的多个时间点出错。这会稍微使事情复杂化，因为 XFS 不会将iomap_flags传输至错误路径中的 iomap 数据结构。要处理这两个问题，首先确保在任一 fs 回调的错误路径中调用清除帮助程序。其次，更新帮助程序以无条件清除标记，只要已填充批次就将其释放。这更清楚地描述了标记用于控制 I/O 路径的目的，而不一定是 fbatch 的状态，因此也围绕此添加了注释。（CVE-2026-90384）

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

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

  - iomap:iomap コールバックが失敗した場合に、Folio バッチをリリースします。関連のないパッチの sashiko レビューでは、iomap ゼロ範囲に使用される Folio バッチメカニズムが、いくつかのエラーシナリオでバッチのリリースに失敗することが指摘されています。->iomap_end() または ->iomap_begin() のどちらかの呼び出しが失敗した場合、直接戻りパスはバッチクリーンアップをバイパスします。->iomap_end() のケースは、このパスからエラーを戻すメカニズムのユーザーが存在しないため、現時点では実際的な問題ではありません。XFSがフィルヘルパーを呼び出し、その後さまざまなポイントでエラーを発生させる可能性があるため、->iomap_begin()のケースは理論的に可能です。XFS はエラーパスの iomap データ構造にiomap_flagsを転送しないため、これは微妙に事態を複雑にします。これらの問題の両方に対処するには、まず、いずれかの fs コールバックのエラーパスでクリーンアップヘルパーを呼び出すようにしてください。次に、ヘルパーを更新して、フラグを無条件にクリアし、バッチが入力されている限りバッチをリリースします。これにより、必ずしも fbatch のステータスではなく、I/O パスを制御するためのフラグの目的がより明確に示されているため、これについてもコメントを追加します。(CVE-2026-90384)

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

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

  - In the Linux kernel, the following vulnerability has been resolved: iomap: release the folio batch on     iomap callback failures A sashiko review of an unrelated patch points out that the folio batch mechanism     used for iomap zero range fails to release the batch in a couple error scenarios. If either calls to
    ->iomap_end() or ->iomap_begin() fail, the direct return paths bypass the batch cleanup. The ->iomap_end()     case is not a practical issue at the moment because there is no user of the mechanism that returns an     error from this path. The ->iomap_begin() case is theoretically possible because XFS can invoke the fill     helper and error out at various points thereafter. This subtly complicates things because XFS does not     transfer iomap_flags to the iomap data structure in the error path. To deal with both of these issues,     first make sure to invoke the cleanup helper in the error path for either fs callback. Second, update the     helper to clear the flag unconditionally and release the batch so long as it is populated. This more     clearly delineates the purpose of the flag to control the I/O path and not necessarily the status of the     fbatch, so add a comment around this as well. (CVE-2026-90384)

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

ID	Name	Product	Family	Published	Updated	Severity
347744	Linux Distros 未修補弱點：CVE-2026-90384	Nessus	Misc.	9/18/2026	11/4/2026	low
347744	Linux Distros 未修补的漏洞：CVE-2026-90384	Nessus	Misc.	9/18/2026	11/4/2026	low
347744	Linux Distros のパッチ未適用の脆弱性: CVE-2026-90384	Nessus	Misc.	9/18/2026	11/4/2026	low
376443	Ubuntu 24.04 LTS / 26.04 LTS : Linux kernel vulnerabilities (USN-8959-1)	Nessus	Ubuntu Local Security Checks	11/5/2026	11/5/2026	high
347744	Linux Distros Unpatched Vulnerability : CVE-2026-90384	Nessus	Misc.	9/18/2026	11/4/2026	low

Detections

Analytics

Plugins Search

low

low

low

high

low