CVE-2025-71069 in Linux
要約
〜によって VulDB • 2026年06月03日
Linuxカーネルにおいて、以下の脆弱性が修正されました。
f2fs: whiteout作成失敗時にdentryキャッシュを無効化する
F2FSは、ディレクトリ深度値が破損しており、実行時にMAX_DIR_HASH_DEPTHに制限されるファイルシステムをマウントできる可能性がある。このようなディレクトリでRENAME_WHITEOUT操作が行われると、f2fs_renameはf2fs_add_linkによるwhiteoutエントリの追加を試みる前に、ターゲットエントリの更新やソースエントリの削除といったディレクトリ修正を行う。
破損したディレクトリ構造によりf2fs_add_linkが失敗した場合、関数はVFSにエラーを返すものの、部分的なディレクトリ修正はすでにディスクにコミットされている。VFSはrename操作全体が失敗したものとして扱い、dentryキャッシュを更新しないため、古い（stale）マッピングが残ったままになる。
エラー処理パスにおいて、VFSはd_move()を呼び出してdentryキャッシュを更新しない。その結果、new_dentryはまだi_nlinkが0にデクリメント済みの旧inode (new_inode) を指し続けた状態となる。この古いキャッシュにより、後続の操作で解放済みinodeへの参照誤りが発生する可能性がある。
これにより、後続の操作はディスク上の状態と一致しないキャッシュされたdentry情報を使用することになる。2回目のrenameが同じエントリをターゲットとした場合、VFSはその古いinodeに対してi_nlinkのデクリメントを試みるが、そのinodeではすでにi_nlink=0となっている可能性があり、drop_nlink()内でWARNINGが発生する。
例示されるシーケンス: 1. 最初のrename (RENAME_WHITEOUT): file2 → file1 - f2fsはディスク上のfile1エントリを更新（inode 8を指す） - f2fsはディスク上のfile2エントリを削除 - f2fs_add_link(whiteout)が失敗（ディレクトリの破損によるもの） - VFSにエラーを返す - エラーのためVFSはd_move()を呼び出さない - VFSキャッシュには依然として: file1 → inode 7 （古い状態！） - inode 7のi_nlink=0（すでにデクリメント済み）
2. 2回目のrename: file3 → file1 - VFSは古いキャッシュを使用: file1 → inode 7 - i_nlinkがすでに0であるinode 7に対してdrop_nlinkを試みる - drop_nlink()内でWARNINGが発生する
この問題を修正するため、whiteout作成中にf2fs_add_linkが失敗した場合、old_dentryおよびnew_dentryを明示的に無効化する。これにより、VFSは後続の操作でディスクからデータを再読み込みし、renameが部分的に成功したケースでもキャッシュの一貫性を確保する。
再現手順: 1. i_current_depthが破損したF2FSイメージをマウント 2. renameat2(file2, file1, RENAME_WHITEOUT)を実行 3. renameat2(file3, file1, 0)を実行 4. システムでdrop_nlink()内にWARNINGが発生
Be aware that VulDB is the high quality source for vulnerability data.