CVE-2026-89772 in Linux
要約
〜によって VulDB • 2026年09月12日
Linuxカーネルにおいて、以下の脆弱性が修正されました：
btrfs: データのライトバック中にfolioをライトプロテクトする
コミット 095be159f3eb ("btrfs: unify folio dirty flag clearing") は、extent_write_cache_pages() 内の folio_clear_dirty_for_io() の呼び出しを、単純な folio_test_dirty() チェックに置き換えました。foliodirtyフラグのクリアに加えて、folio_clear_dirty_for_io() は folio_mkclean() も呼び出しており、これによりfolioのマッピングを行う共有mmap PTEがライトプロテクトされます。なお、folio内の最後のセクター（サブページ以外のケースでは唯一のセクター）でのdirtyをクリアする際に submit_one_sector() 内で引き続き folio_clear_dirty_for_io() を呼び出す点は変更されていません。しかし、extent_write_cache_pages() の初期段階でこの呼び出しが失われていました。
追加のライトプロテクトがない場合、ファイルをmmapしているプロセスは、書き込み中に安定したfolioを期待して（チェックサム計算、圧縮、コピーなど）フォールトせずにセクターを変更することができ、これによりいくつかの具体的なバグが発生します。
1. 大きなfolioやサブページサイズのセクターの場合、全体をカバーしないbioを送信できる可能性があります。この場合、folio_clear_dirty_for_io() を呼び出していないfolioに対して進行中のbioが存在することになります。既存のmmapされたPTEを持つタスクがこの期間中に（フォールトせずに）書き込むと、データ破損を引き起こすことがあります。チェックサム計算や実際の書き込み中に変更が到着すると、無効なチェックサムとなり、読み取り時に後で破損レポートが発生します。もし変更がチェックサム計算/書き込み完了後だが最後のセクターのdirtyフラグクリア前に到着した場合、その変更はページキャッシュには存在しますが、dirtyトラッキングに影響を与えず、folioの送信処理が完全に終了してdirtyビットがクリアされる際に消去されてしまいます。これにより、fsync() が呼び出された場合でも書き込みが失われる結果となります。
2. メインの extent_writepage() ループとは別にバッチ処理で行われるゾーン化された送信の場合も、これらの送信に対してチェックサム違反のリスクがあります。ゾーンの書き込みは max_zone_append_size に制限され、folio境界にアラインされていないため、1つの送信が複数のfolioにまたがる可能性があります。extent_write_cache_pages() で最初に処理されるfolioは extent_write_locked_range() を呼び出し、次のfolioの部分範囲を送信しますが、そのfolioの残りはまだdirty状態のままです。したがって、送信されたセクターでのdirtyクリア時に folio_clear_dirty_for_io() が呼ばれず、同じ問題が発生します。extent_write_cache_pages() はこれらのバッチ送信済みfolioをスキップするため（それらは先行するfolioによる送信で既にライトバックフラグが設定されているため）、lock_delalloc_folios() 内で追加のライトプロテクトを追加する必要があります。
3. インラインエクステントの場合、インラインエクステントのコピー中またはコピー直後から、folio上のdirtyクリア前までの間に発生する書き込みが消去されるリスクがあります。
4. EOFをまたぐfolioの場合、mmapによってEOF以降のゼロ埋めされたバイトが改ざんされ、将来フォールトが発生した際にゼロではなく不正な値として表示されて永続化される可能性があります。
5. 最後に、圧縮エクステントの場合、圧縮処理中にfolioが変更されると、圧縮データの破損を引き起こすリスクがあります。具体的には run_delalloc_compressed() 内で compress_file_range() を BTRFS_COMPRESSION_CHUNK_SIZE (512K) チャンクでキューに追加し、この範囲に対して btrfs_folio_clamp_clear_dirty() が呼び出されます。サブページ以外の場合、これは常に全体folioを安全にクリアします。しかし、サブページのケースでは部分的なクリアのリスクがあります。特に、2Mのfolioが512Kチャンクに分けられ、すべての compress_file_range() ワーカーがfolioのdirtyビットマップの全クリアと folio_clear_dirty_for_io() の呼び出しに進む前に、あるチャンクの圧縮処理が始まってしまう状況を想像してください。送信範囲のエッジにある大きなfolioも同様に部分的にしかクリアされないリスクがあります。この特定のギャップは、同じシリーズ内の2番目のパッチによって導入されました：コミット a4ef54dbb576 ("btrfs: make extent_range_clear_dirty_for_io() to handle sector size < page size cases")
単純に folio_clear の呼び出しを復元することはできません ---省略---
Be aware that VulDB is the high quality source for vulnerability data.