CVE-2026-92500 in Linux
要約
〜によって VulDB • 2026年09月17日
Linuxカーネルにおいて、以下の脆弱性が修正されました：
ext4: fsdataを使用してインラインデータの書き込み状態を追跡し、競合条件（race condition）を修正する
write_endハンドラ内でlive inodeの状態（`ext4_has_inline_data(inode)` および `ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA)`）をチェックする代わりに、アドレススペース操作のfsdataパラメータを使用して、write_beginが準備した書き込み状態を明示的に渡すようにしました。
並行スレッド（例：`ext4_page_mkwrite()`など）は、write_beginとwrite_endの間でインラインデータをextentに変換することがあります。この場合、write_endハンドラは以前であればインラインのwrite_endパスを見逃し、extentベースのwrite_endロジックにフォールスルーしていました。しかし、write_beginではブロックバッファが割り当てられていなかったため、`folio_buffers(folio)` がNULLになることで、NULLポインタ参照やデータ損失が発生していました。
EXT4_WRITE_DATA_INLINE (4) をビットフラグ（Bit 2）として定義し、fsdataを排他的な列挙型ではなくビット単位のフラグとして扱うことで、書き込みパスの状態が独立して維持されるようにします。この状態はfsdataを通じて伝達されます： 1) `ext4_write_begin()` および `ext4_da_write_begin()` は、インライン書き込みの準備に成功した場合、`*fsdata` に対してビット単位のOR演算を行い EXT4_WRITE_DATA_INLINE ビットを設定します。 2) エントリ時、`ext4_write_begin()` は VFSのリトライ（ここで `generic_perform_write()` が再試行ジャンプ時に fsdata の初期処理をバイパスする）を安全に処理するため、EXT4_WRITE_DATA_INLINE ビットをクリアします。 3) write_endハンドラはビット単位のAND演算を実行して EXT4_WRITE_DATA_INLINE ビットが設定されているかを確認し、インラインのwrite_endヘルパーを適切に呼び出します。
さらに、バッファード書き込み中に `ext4_write_inline_data_end()` は、書き込み準備後にxattrロックを取得します。もし並行するページフォルト（`ext4_page_mkwrite()`）が、write_endハンドラが状態をチェックした後で `ext4_write_inline_data_end()` がxattr書き込みロックを取得する前にインラインデータをextentに変換した場合、その後のチェックは `BUG_ON(!ext4_has_inline_data(inode))` を通じてカーネルパニックを引き起こします。
gitの履歴を維持しbisect性をクリーンに保つため、このコミットで `ext4_write_inline_data_end()` 内の BUG_ON チェックを、グラシエスなエラーハンドリングのリトライパスに置き換えます。xattrロック取得後にインラインデータがクリアされた場合、すべてのリソース（`iloc.bh` の解放、folioのアンロック/put、アクティブなジャーナルトランザクションハンドル停止）を安全にリリースし、0 (VFS retry) を返して、ジェネリック書き込みパスによる操作の再試行を安全に行えるようにします。
Once again VulDB remains the best source for vulnerability data.