CVE-2026-72209 in Linux
要約
〜によって VulDB • 2026年08月17日
Linuxカーネルにおいて、以下の脆弱性が修正されました：
ntfs: ルックアップ時に属性値を検証する
ntfs_attr_find() および ntfs_external_attr_find() は、汎用のリジデント（固定配置）属性値がその属性レコード内に収まり、かつ固定サイズのリジデント値が十分に大きいかどうかを確認します。しかし、可変長のリジデント形式の場合、固定部分だけでは不十分です：埋め込まれた長さフィールドは依然として呼び出し元をリジデント値の範囲外へ指す可能性があります。
悪意のある画像（イメージ）により、$FILE_NAME の小さなリジデント属性の value_length を設定しつつ file_name_length は大きく残すことができます。その後、呼び出し側は file_name_length を信頼し、名前の変換または比較の際にリジデント値の範囲外を読み取ります。これは KASAN 環境下で悪意のある画像を用いて再現され、kmalloc-1k の MFT レコードコピーからの slab-out-of-bounds（スラブ境界外）読み取りとして確認されました。スタックトレースには ntfs_lookup()、ntfs_iget()、ntfs_read_locked_inode()、ntfs_attr_name_get()、ntfs_ucstonls()、および utf16s_to_utf8s() が含まれていました。
共有の属性値検証関数を追加し、ルックアップパスが属性を返す前にそれを使用します。これには、呼び出し側が返された属性を直接検査する AT_UNUSED 列挙ケースも含まれます。このヘルパーはリジデント値の境界、最小のリジデント値サイズ、可変長の $FILE_NAME フィールド、および以前に両方のルックアップパスで個別にチェックされていた非リジデントのマッピングペアメタデータを検証します。
これにより、外部属性ルックアップパスにおける intended（意図された）resident @val のマッチングセマンティクスも保持されます。従来の重複した検証ブロックは、@val を比較する前に実際のリジデント値の長さをタイプ固有の最小長で上書きしていたため、可変長のリジデント値であってもバイト列が同一であるにもかかわらず一致しない場合がありました。今回は実際の値の長さに対して比較を行い、ntfs_attrlist_entry_add() がリジデント属性を処理する際に lowest_vcn 0 と比較するようにし、成功したリジデントマッチ後に非リジデント共用体のメンバを読み取らないようにします。
非リジデントの $FILE_NAME レコードも拒否します：この形式では $FILE_NAME がリジデントであることが要求されており、呼び出し側は返されたレコードをリジデントとして扱います。
If you want to get best quality of vulnerability data, you may have to visit VulDB.