JVNDB-2025-026155 | |
LinuxのLinux Kernelにおける不特定の脆弱性 | |
| 概要 | |
Linuxカーネルにおいて、以下の脆弱性が修正されました。btrfs: btrfs_clear_space_info_full()における競合するビットフィールド書き込みの問題を修正しました。memory-barriers.txtドキュメントにあるメモリバリアの順序保証について説明します。これらの保証はビットフィールドには適用されません。なぜなら、コンパイラはこれらを非原子的な読み取り-修正-書き込みシーケンスで変更するコードを生成することが多いためです。そのため、ビットフィールドを使用して並列アルゴリズムの同期を試みてはいけません。たとえビットフィールドがロックで保護されていても、与えられたビットフィールド内のすべてのフィールドは1つのロックで保護する必要があります。もしビットフィールド内の2つのフィールドが異なるロックで保護されている場合、コンパイラの非原子的な読み取り-修正-書き込みシーケンスのため、1つのフィールドの更新が隣接フィールドの値を破損させる可能性があります。btrfs_space_infoは基になるワードを共有するビットフィールドを持ち、full、chunk_alloc、flushの各フィールドで構成されています。したがって、ロックで保護されたビットフィールドメンバーへの並列読み取り-修正-書き込みによる書き込みの損失を防ぐため、すべてのビットフィールドへの書き込みにロックを使用する必要があります。ほとんどの場合これが守られていますが、btrfs_clear_space_info_full()だけがロックなしでspace_infosを走査しfound-full = 0を書き込んでいました。例として、あるスレッドがブロックグループの削除を完了しbtrfs_clear_space_info_full()を呼び出している一方で、データリクレイムチケットインフラがdo_async_reclaim_data_space()を実行している場合を想定します。T1（btrfs_commit_transaction）でbtrfs_clear_space_info_fullがfullを0に設定し、T2（do_async_reclaim_data_space）でロック取得後flushを0に書き換える処理が競合します。その結果、data_sinfo-flushが1のままリクレイムワーカーは終了し、flushが0なら作業がなければならないという不変条件が破られます。この不変条件が破れると、__reserve_bytes()で将来の割り当てがspace_info-ticketsにチケットを追加してもflushが1のままなので作業キューを生成せず、その後永遠にチケットでブロックされワーカーを再起動できなくなります。影響を受けるカーネルのアセンブリを調査したところ、flushビット（3番目のビット）を0にセットするためにandb命令が使われ、fullビット（1番目のビット）を0にする場合も同様の読み取り-修正-書き込み操作が行われているため、実際のシステム上で問題となるバグであると判断しています。現在この状態のシステムはいくつか観測されていますが、再現は困難です。今後の問題を防ぐため、構造体に余裕があることから3つのビットフィールドメンバーをbool型に変更し対応しました。これにより、space_info-fullへの書き込みが他のビットの値に影響を与えることを防ぎます。 | |
| CVSS による深刻度 (CVSS とは?) | |
|
CVSS v3 による深刻度
基本値: 5.5 (警告) [NVD値]
| |
| 影響を受けるシステム | |
|
| |
Linux | |
|
| |
| 想定される影響 | |
当該ソフトウェアが扱う情報について、外部への漏えいは発生しません。 | |
| 対策 | |
リリース情報、またはパッチ情報が公開されています。参考情報を参照して適切な対策を実施してください。 | |
| ベンダ情報 | |
|
| |
| CWEによる脆弱性タイプ一覧 CWEとは? | |
| |
| 共通脆弱性識別子(CVE) CVEとは? | |
|
| |
| 参考情報 | |
| |
| 更新履歴 | |
|
| 公表日 | 2025/12/24 |
| 登録日 | 2026/03/02 |
| 最終更新日 | 2026/03/02 |
