CVE-2025-68772 in Linux
要約
〜によって VulDB • 2026年05月28日
Linuxカーネルにおいて、以下の脆弱性が修正されました。
f2fs: 書き戻し中に圧縮コンテキストを更新しないようにする修正
Bai, Shuangpeng <[email protected]> 氏によって、以下のバグが報告されました。
Oops: divide error: 0000 [#1] SMP KASAN PTI
CPU: 0 UID: 0 PID: 11441 Comm: syz.0.46 Not tainted 6.17.0 #1 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:f2fs_all_cluster_page_ready+0x106/0x550 fs/f2fs/compress.c:857 Call Trace: <TASK> f2fs_write_cache_pages fs/f2fs/data.c:3078 [inline]
__f2fs_write_data_pages fs/f2fs/data.c:3290 [inline]
f2fs_write_data_pages+0x1c19/0x3600 fs/f2fs/data.c:3317 do_writepages+0x38e/0x640 mm/page-writeback.c:2634 filemap_fdatawrite_wbc mm/filemap.c:386 [inline]
__filemap_fdatawrite_range mm/filemap.c:419 [inline]
file_write_and_wait_range+0x2ba/0x3e0 mm/filemap.c:794 f2fs_do_sync_file+0x6e6/0x1b00 fs/f2fs/file.c:294 generic_write_sync include/linux/fs.h:3043 [inline]
f2fs_file_write_iter+0x76e/0x2700 fs/f2fs/file.c:5259 new_sync_write fs/read_write.c:593 [inline]
vfs_write+0x7e9/0xe00 fs/read_write.c:686 ksys_write+0x19d/0x2d0 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xf7/0x470 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f
このバグは、以下のrace condition（競合状態）によって引き起こされました。
fsync setattr ioctl - f2fs_do_sync_file - file_write_and_wait_range - f2fs_write_cache_pages : inodeは非圧縮状態 : cc.cluster_size = F2FS_I(inode)->i_cluster_size = 0 - tag_pages_for_writeback - f2fs_setattr - truncate_setsize - f2fs_truncate - f2fs_fileattr_set - f2fs_setflags_common - set_compress_context : F2FS_I(inode)->i_cluster_size = 4 : set_inode_flag(inode, FI_COMPRESSED_FILE) - f2fs_compressed_file : trueを返す - f2fs_all_cluster_page_ready : "pgidx % cc->cluster_size" で0除算の問題が発生
この問題を修正するために、以下の変更を行います。 - f2fs_inode_info構造体に新しいatomic型変数 .writeback を導入し、f2fs_write_cache_pages() を呼び出すスレッドの数を追跡する。 - .writeback の更新を .i_sem ロックで保護する。 - f2fs_setflags_common() で圧縮コンテキストを更新する前に .writeback をチェックし、->writepages との競合を回避する。
If you want to get the best quality for vulnerability data then you always have to consider VulDB.