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

  - btrfs：数据回写提交期间的写保护 Folio 095be159f3eb（btrfs：统一 Folio 脏标记清除） 将 extent_write_cache_pages（） 中的 folio_clear_dirty_for_io（） 调用替换为普通 folio_test_dirty（） 检查。除了清除脏标记外，folio_clear_dirty_for_io（） 还会调用 folio_mkclean（），对映射 folio 的共享 mmap PTE 进行写保护。请注意，稍后在 submit_one_sector（） 中，当我们在作品集的最后一个扇区（非子页面情况的唯一扇区）上清除脏时，仍然会调用 folio_clear_dirty_for_io（）。但我们在 extent_write_cache_pages（） 中失去了这个早期的电话。
    如果没有额外的写保护，使用 mmap-ed 文件的进程可在回写使用扇区时修改扇区，其期望得到稳定的 folio（校验和、压缩、复制等）而不发生错误，表现为一些具体的缺陷。1. 对于大型对开本或子页面扇区大小，可以提交不涵盖整个对开本的简历。当这种情况发生时，我们将有一个我们 *不* 调用 folio_clear_dirty_for_io（） 的对开本的简历。如果具有现有 mmap-ed PTE 的任务在此窗口中写入（没有错误..），则可导致损坏。如果写入在校验和或写入本身正在进行时到达，这可导致无效的校验和，并且稍后会在读取时造成损坏报告。如果写入是在校验和/写入完成后，但在清除最后一个脏扇区之前到达的，则写入存在于页面缓存中，但不会影响脏跟踪，并且将在完全完成提交作品集并清除脏位时丢失。这会导致即使调用 fsync（） 也会丢失写入。2. 对于与主 extent_writepage（） 循环分批完成的分区提交，我们还存在这些提交违反 csum 的风险。分区写入被限制在max_zone_append_size上并且与作品集不对齐，因此提交可以跨越两个作品集。在 extent_write_cache_pages（） 中处理的第一个作品集将调用 extent_write_locked_range（），后者将提交下一个作品集的部分范围，而该作品集的其余部分仍可能是脏的。因此，清除提交的扇区脏不会调用 folio_clear_dirty_for_io（），我们遇到同样的问题。由于 extent_write_cache_pages（） 会跳过这些批量提交的作品集（它们已被前面的作品集标记为从提交中进行回写），因此我们必须在 lock_delalloc_folios（） 中添加额外的写保护。3. 对于内联盘区，这将微妙地存在丢失写入的风险，这些写入发生在我们复制内联盘区之后/期间，但在我们清除作品集上的脏盘区之前。4.
    对于跨 EOF 的作品集，mmap 可篡改过去 EOF 的归零字节，并造成在未来的错误无法正确看到它们而非零的情况下保留这些字节。5. 最后，对于压缩盘区，我们在压缩作品集时冒着修改作品集的风险，这将导致压缩数据损坏。具体来说，在 run_delalloc_compressed（） 中，我们将工作排队以在 BTRFS_COMPRESSION_CHUNK_SIZE （512K） 区块中执行 compress_file_range（），这些区块将调用该范围内的 btrfs_folio_clamp_clear_dirty（）。
    对于非子页面，这将始终安全地清除整个作品集。对于子页面，我们在这里也冒着部分清除的风险。特别是，想象一个 2M 作品集被分解成 512K 的工作块，这些工作块可能会在所有块 compress_file_range（） 工作线程足够远以完成清除作品集的所有脏位图并进入 folio_clear_dirty_for_io（） 之前开始对一个块进行压缩工作。提交范围边缘的大型作品集同样面临仅部分清除的风险。该系列中的另一个修补程序引入了这一特殊差距：提交 a4ef54dbb576（btrfs：使 extent_range_clear_dirty_for_io（） 处理扇区大小<页面大小情况）我们不能简单地将调用还原为 folio_clear ---truncated--- （CVE-2026-89772）

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

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

  - Btrfs：資料回寫提交 095be159f3eb 期間的寫入保護對開本 （Btrfs：統一對開本已變更旗標清除） 以純 folio_test_dirty（） 檢查取代了 extent_write_cache_pages（） 中的 folio_clear_dirty_for_io（） 呼叫。除了清除已變更旗標外，folio_clear_dirty_for_io（） 也會呼叫 folio_mkclean（），以寫入保護對應對應對應作品集的共用 mmap PTE。請注意，當我們在對開本的最後一個扇區（非子頁面情況的唯一扇區）上清除 dirty 時，我們仍然會在 submit_one_sector（） 中稍後調用 folio_clear_dirty_for_io（）。但我們在 extent_write_cache_pages（） 中失去了這個早期的呼叫。
    如果沒有額外的寫入保護，具有 mmap-ed 檔案的處理程序可以在回寫使用磁區時修改磁區，其方式需要穩定的對開本 （總和檢查碼、壓縮、複製等...），而不會出現錯誤，這表現為一些具體的錯誤。1. 對於較大的對開本或子頁面扇區大小，可以提交不涵蓋整個對開本的簡歷。當這種情況發生時，我們將有一個我們*未*調用 folio_clear_dirty_for_io（） 的對開本的簡歷。如果具有現有 mmap-ed PTE 的工作在此視窗中寫入 （沒有錯誤..） ，可能會導致損毀。如果寫入在總和檢查碼或寫入本身進行時到達，這可能會導致總和檢查碼無效，並在讀取時報告稍後的損毀報告。如果寫入在總和檢查碼/寫入完成之後，但在清除最後一個已變更磁區之前到達，則該寫入存在於頁面快取中，但不會影響已變更追蹤，且當對開本完全完成提交且已清除已變更位時，寫入將會遺失。這會導致即使呼叫 fsync（） 也會遺失寫入。2. 對於與主 extent_writepage（） 迴圈分批完成的分區提交，我們還面臨這些提交違反 csum 的風險。分區寫入會限制為max_zone_append_size，且未與對開本對齊，因此提交可以跨越兩個對開本。在 extent_write_cache_pages（） 中處理的第一個對開本將呼叫 extent_write_locked_range（），該對開本將提交下一個對開本的部分範圍，而該對開本的其餘部分可能仍然是髒的。因此，在提交的扇區上清除髒東西不會調用 folio_clear_dirty_for_io（），我們有同樣的問題。由於 extent_write_cache_pages（） 會略過這些批次提交的對開本 （這些對開本已由前一個對開本標示為從提交中回寫），因此我們必須在 lock_delalloc_folios（） 中新增額外的寫入保護。3. 對於內嵌範圍，這將微妙地面臨丟失寫入的風險，這些寫入發生在我們複製內嵌範圍之後/期間，但在我們清除對開本上的髒東西之前。4.
    對於跨越 EOF 的對開本，mmap 可能會竄改 EOF 之後的歸零位元組，並導致它們在未來的錯誤會不正確地看到它們而不是零的情況下被保留。5. 最後，對於壓縮範圍，我們在壓縮對開本時可能會修改對開本，這將導致壓縮資料損毀。具體來說，在 run_delalloc_compressed（） 中，我們將工作排隊以在 BTRFS_COMPRESSION_CHUNK_SIZE （512K） 區塊中執行 compress_file_range（），這些區塊將呼叫該範圍內的 btrfs_folio_clamp_clear_dirty（）。
    對於非子頁面，這將始終安全地清除整個作品集。對於子頁面，我們在這裡也冒著部分清除的風險。特別是，想像一個 2M 作品集被分解成 512K 個工作區塊，這些工作區塊可能會在所有區塊 compress_file_range（） 工作者足夠遠以完成清除作品集的所有髒點陣圖並到達 folio_clear_dirty_for_io（） 之前開始在一個區塊上進行壓縮工作。提交範圍邊緣的大型對開本同樣面臨僅部分清除的風險。這個特殊的差距是由同一系列中的第二個修補程式引入的：提交 a4ef54dbb576 （btrfs：使 extent_range_clear_dirty_for_io（） 處理磁區大小<頁面大小情況） 我們不能簡單地恢復對 folio_clear ---truncated--- （CVE-2026-89772） 的調用

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

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

  - btrfs:データライトバックコミット 095be159f3eb 中の Folio を書き込み保護(btrfs:Folio ダーティフラグのクリアを統一) extent_write_cache_pages() の folio_clear_dirty_for_io() 呼び出しをプレーンな folio_test_dirty() チェックと置換しました。ダーティフラグを消去するだけでなく、folio_clear_dirty_for_io() は folio_mkclean() も呼び出し、フォリオをマッピングする共有 mmap PTE を書き込み保護します。注意:フォリオの最後のセクター(非サブページの場合のための唯一のセクター)で dirty を消去する際に、submit_one_sector() の後半で folio_clear_dirty_for_io() を呼び出します。しかし、extent_write_cache_pages()でこの早いコールに負けました。
    追加の書き込み保護がない場合、ファイル mmap-ed のプロセスは、ライトバックに使用されている間にセクターを変更でき、フォールトのない安定した folio(チェックサム、圧縮、コピーなど)を期待します。これは、いくつかの具体的なバグとして現れます。1. 大きなフォリオまたはサブページのセクターサイズの場合、フォリオ全体をカバーしない経歴を提出することが可能です。これが発生すると、folio_clear_dirty_for_io() を呼び出していない * 未呼び出し * の Folio のバイオが処理中になります。既存の mmap 化された PTE を持つタスクがこのウィンドウに(障害なしに)書き込みを行うと、破損する可能性があります。チェックサムまたは書き込み自体の進行中に書き込みが到着すると、チェックサムが無効になり、後に読み取り時に破損が報告される可能性があります。書き込みがチェックサム/書き込み完了後、最後のセクター dirty がクリアされる前に到着した場合、書き込みはページキャッシュに存在しますが、ダーティ追跡には影響せず、フォリオの送信が完全に終了し、ダーティビットがクリアされると失われます。これにより、fsync() が呼び出されても書き込みが失われます。2. メインの extent_writepage() ループとは別のバッチで行われるゾーン付き送信については、それらの送信に対して csum 違反のリスクもあります。ゾーン書き込みはmax_zone_append_sizeにクランプされ、フォリオと整列されないため、提出は 2 つのフォリオにまたがる可能性があります。extent_write_cache_pages() で処理されている最初の Folio は extent_write_locked_range() を呼び出し、次の Folio の一部範囲を送信しますが、その Folio の残りの部分はまだダーティである可能性があります。したがって、送信されたセクターで dirty をクリアしても folio_clear_dirty_for_io() は呼び出されず、同じ問題が発生します。extent_write_cache_pages() はこれらのバッチ送信された Folio をスキップするため (前の Folio による送信からの書き戻しのマークがすでに付けられています)、lock_delalloc_folios() で書き込み保護を追加する必要があります。3.インラインエクステントの場合、インラインエクステントをコピーした後/最中、フォリオでダーティをクリアする前に発生する書き込みが失われるリスクが微妙にあります。4.
    EOF をまたがるフォリオでは、mmap が EOF を超えたゼロバイトを改ざんし、将来の障害時にゼロではなく不適切に表示されるようなバイトが永続化される可能性があります。5. 最後に、圧縮されたエクステントの場合、圧縮作業中にフォリオを変更すると、圧縮データが破損するリスクがあります。具体的には、run_delalloc_compressed()では、BTRFS_COMPRESSION_CHUNK_SIZE(512K)チャンクでcompress_file_range()を実行する作業をキューに入れます。これにより、その範囲でbtrfs_folio_clamp_clear_dirty()が呼び出されます。
    非サブページの場合、これにより、常にフォリオ全体が安全にクリアされます。サブページについては、ここでも部分的にクリアされるリスクがあります。特に、2Mのフォリオが512Kの作業チャンクに分割され、すべてのチャンクcompress_file_range()ワーカーがフォリオのすべてのダーティビットマップをクリアしてfolio_clear_dirty_for_io()に到達する前に、1つのチャンクで圧縮作業を開始する可能性があると想像してください。提出範囲の端にある大きなフォリオも同様に、部分的にしかクリアされないリスクがあります。この特定のギャップは、同じシリーズの 2 番目のパッチによって導入されました: a4ef54dbb576 commit(btrfs:ページサイズの場合にセクターサイズを処理するために extent_range_clear_dirty_for_io() を作成<)folio_clear ---truncated--- への呼び出しを単純に復元することはできません(CVE-2026-89772)

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

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

  - btrfs: write-protect folios during data writeback commit 095be159f3eb (btrfs: unify folio dirty flag     clearing) replaced the folio_clear_dirty_for_io() call in extent_write_cache_pages() with a plain     folio_test_dirty() check. Besides clearing the dirty flag, folio_clear_dirty_for_io() also calls     folio_mkclean(), which write-protects the shared mmap PTEs mapping the folio. Note that we still do call     folio_clear_dirty_for_io() later in submit_one_sector() when we clear dirty on the last sector of the     folio (the only sector for non-subpage cases). But we lost this early call in extent_write_cache_pages().
    Without the extra write-protection, a process with the file mmap-ed can modify a sector while it is being     used by writeback in a way that expects a stable folio (checksumming, compressing, copying, etc...)     without faulting, which manifests as a handful of concrete bugs. 1. For large folios or subpage     sectorsize, it is possible to submit a bio which does not cover the whole folio. When this happens, we     will have a bio in flight for a folio that we have *not* called folio_clear_dirty_for_io() on. If a task     with an existing mmap-ed PTE writes (without faulting..) in this window, it can result in corruptions. If     the write arrives while the checksumming or writing itself is underway, this can result in an invalid     checksum and later corruption reports on read. If the write arrives after checksumming/writing is done but     before the last sector dirty is cleared, then the write is present in page cache but doesn't affect the     dirty tracking and will be lost when the folio is fully finished being submitted and the dirty bit is     cleared. This results in losing the write even if fsync() is called. 2. For zoned submissions which are     done in batch separate from the main extent_writepage() loop, we also risk csum violations for those     submissions. Zoned writes are clamped to max_zone_append_size and are not aligned with folios, so a     submission can span two folios. The first folio being processed in extent_write_cache_pages() will call     extent_write_locked_range() which will submit the partial range of the next folio, while the rest of that     folio could still be dirty. So clearing dirty on the submitted sectors doesn't call     folio_clear_dirty_for_io() and we have the same issue. Since extent_write_cache_pages() skips these batch     submitted folios (they are already marked for writeback from submission by the preceding folio), we must     add the extra write protection in lock_delalloc_folios(). 3. For inline extents this will subtly risk     losing writes that happen after/while we copy the inline extent but before we clear dirty on the folio. 4.
    For folios spanning EOF, mmap could tamper with the zeroed bytes past EOF and cause them to be persisted     where future faults would improperly see them instead of zeros. 5. Finally, for compressed extents, we     risk modifying the folios while we work on compressing them which will result in corrupted compressed     data. Specifically, in run_delalloc_compressed() we queue up work to do compress_file_range() in     BTRFS_COMPRESSION_CHUNK_SIZE (512K) chunks which will call btrfs_folio_clamp_clear_dirty() on the range.
    For non-subpage, this will always clear the whole folio, safely. For subpage, we risk a partial clear here     as well. In particular, imagine a 2M folio broken up into 512K chunks of work which might start     compression work on one chunk before all the chunks compress_file_range() workers have gotten far enough     to finish clearing all the dirty bitmaps of the folio and getting to folio_clear_dirty_for_io(). Large     folios on the edges of submission ranges are similarly at risk to be only partly cleared. This particular     gap was introduced by a second patch in the same series: commit a4ef54dbb576 (btrfs: make     extent_range_clear_dirty_for_io() to handle sector size < page size cases) We cannot simply restore the     call to folio_clear ---truncated--- (CVE-2026-89772)

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

ID	Name	Product	Family	Published	Updated	Severity
345046	Linux Distros 未修补的漏洞：CVE-2026-89772	Nessus	Misc.	9/12/2026	9/23/2026	high
345046	Linux Distros 未修補弱點：CVE-2026-89772	Nessus	Misc.	9/12/2026	9/23/2026	high
345046	Linux Distros のパッチ未適用の脆弱性: CVE-2026-89772	Nessus	Misc.	9/12/2026	9/23/2026	high
345046	Linux Distros Unpatched Vulnerability : CVE-2026-89772	Nessus	Misc.	9/12/2026	9/23/2026	high

Detections

Analytics

Plugins Search

high

high

high

high