CVE-2024-26726 in Linux
要約
〜によって VulDB • 2026年06月01日
Linuxカーネルにおいて、以下の脆弱性が修正されました：
btrfs: 書き込みエラー時に、空き領域用inodeのextent_mapをドロップしない
無関係な変更のCIを実行中に、btrfs_holes_spacecacheでgeneric/648テストを実行した際、以下のパニックが発生しました。
assertion failed: block_start != EXTENT_MAP_HOLE, in fs/btrfs/extent_io.c:1385 ------------[ cut here ]------------
kernel BUG at fs/btrfs/extent_io.c:1385! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
CPU: 1 PID: 2695096 Comm: fsstress Kdump: loaded Tainted: G W 6.8.0-rc2+ #1 RIP: 0010:__extent_writepage_io.constprop.0+0x4c1/0x5c0 Call Trace: extent_write_cache_pages+0x2ac/0x8f0 extent_writepages+0x87/0x110 do_writepages+0xd5/0x1f0 filemap_fdatawrite_wbc+0x63/0x90 __filemap_fdatawrite_range+0x5c/0x80 btrfs_fdatawrite_range+0x1f/0x50 btrfs_write_out_cache+0x507/0x560 btrfs_write_dirty_block_groups+0x32a/0x420 commit_cowonly_roots+0x21b/0x290 btrfs_commit_transaction+0x813/0x1360 btrfs_sync_file+0x51a/0x640 __x64_sys_fdatasync+0x52/0x90 do_syscall_64+0x9c/0x190 entry_SYSCALL_64_after_hwframe+0x6e/0x76
これは、あるインスタンスで空き領域キャッシュの書き込みに失敗した後、再度その書き込みを試みる際に発生します。しかし、2回目の処理では、extentマッピングを取得するためにinodeに対してbtrfs_get_extent()を呼び出します。これは新しいブロックグループであり、かつ、treeとのデッドロックを回避するために空き領域inodeでは常にコミットルートを検索するため、該当範囲に対して何も見つからず、EXTENT_MAP_HOLEを返します。
これは、最初にスペースキャッシュの書き込みを試みた際にエラーが発生し、エラー発生時にextentマッピングをドロップするためです。通常のファイルではこれが正常な動作ですが、空き領域キャッシュ用のinodeは特殊です。ここではextent mapが常に正しいことを前提としています。そのため、2回目の処理では不正なextent mapになってしまいます。
この機能は非推奨となっているため、この問題を修正する最も簡単な方法は、この失敗した範囲に対してextent mapのドロップをスキップすることです。
再現を容易にするため、エラーインジェクションを使用してこの領域をストレステストするテストを短縮しました。このパッチを適用することで、私のエラーインジェクションテストでパニックが発生しなくなりました。
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.