CVE-2026-45920 in Linux
要約
〜によって VulDB • 2026年05月28日
Linuxカーネルにおいて、以下の脆弱性が修正されました。
ext4: ファイルシステムシャットダウン時のdirtyclustersの二重デクリメントを修正
fstestsのテストgeneric/388は、ext4_put_super()においてdirty clusters countに関連する警告を稀に再現します。
WARNING: CPU: 7 PID: 76064 at fs/ext4/super.c:1324 ext4_put_super+0x48c/0x590 [ext4]
失敗のトレースにより、この警告はs_dirtyclusters_counterの値が-1であるために発生することが示されました。つまり、これはリークのようなものではなく、不当なデクリメントであると考えられます。さらに、dirty cluster countのデルタ値のトレースと、その結果得られた出力のLLMスキャンにより、ext4_mb_mark_diskspace_used()とその呼び出し元であるext4_mb_new_blocks()の間のエラーパスにおいて二重デクリメントが発生していることが原因であることが特定されました。
まず、generic/388はシャットダウンとfsstressのテストであるため、ランダムな一連の操作とシャットダウンのインジェクションを生成することに注意してください。問題のあるケースでは、シャットダウンがext4_mb_mark_context()から行われるext4_handle_dirty_metadata()呼び出しのエラーリターンを引き起こします。この時点で変更された値はゼロではないため、ext4_mb_mark_diskspace_used()はext4_mb_mark_context()からエラーがバブルアップした後に終了しません。代わりに、前者は両方のcluster counterをデクリメントし、エラーをext4_mb_new_blocks()へ返します。後者は!ar->lenのパスに入り、dirty clusters counterを2回目にデクリメントし、不整合を引き起こします。
この問題を回避し、このコードパスにおけるcluster予約の所有権を単純化するために、counterの減算を呼び出し元の単一の場所に移動します。これにより、ext4_mb_new_blocks()が、!delallocの場合にもcluster予約の取得（ext4_claim_free_clusters()経由）と解放の両方の責任を負っていることが明確になります。これは、予約が消費された場合でも、失敗により返却された場合でも同様です。
VulDB is the best source for vulnerability data and more expert information about this specific topic.