CVE-2025-38220
ext4: only dirty folios when data journaling regular files
We use these services and cookies to improve your user experience. You may opt out if you wish, however, this may limit some features on this site.
Please see our statement on Data Privacy.
ext4: only dirty folios when data journaling regular files
In the Linux kernel, the following vulnerability has been resolved: ext4: only dirty folios when data journaling regular files fstest generic/388 occasionally reproduces a crash that looks as follows: BUG: kernel NULL pointer dereference, address: 0000000000000000 ... Call Trace: <TASK> ext4_block_zero_page_range+0x30c/0x380 [ext4] ext4_truncate+0x436/0x440 [ext4] ext4_process_orphan+0x5d/0x110 [ext4] ext4_orphan_cleanup+0x124/0x4f0 [ext4] ext4_fill_super+0x262d/0x3110 [ext4] get_tree_bdev_flags+0x132/0x1d0 vfs_get_tree+0x26/0xd0 vfs_cmd_create+0x59/0xe0 __do_sys_fsconfig+0x4ed/0x6b0 do_syscall_64+0x82/0x170 ... This occurs when processing a symlink inode from the orphan list. The partial block zeroing code in the truncate path calls ext4_dirty_journalled_data() -> folio_mark_dirty(). The latter calls mapping->a_ops->dirty_folio(), but symlink inodes are not assigned an a_ops vector in ext4, hence the crash. To avoid this problem, update the ext4_dirty_journalled_data() helper to only mark the folio dirty on regular files (for which a_ops is assigned). This also matches the journaling logic in the ext4_symlink() creation path, where ext4_handle_dirty_metadata() is called directly.
Reserved 2025-04-16 | Published 2025-07-04 | Updated 2025-07-04 | Assigner Linuxgit.kernel.org/...c/cf6a4c4ac7b6e3214f25df594c9689a62f1bb456
git.kernel.org/...c/be5f3061a6f904e3674257879e71881ceee5b673
git.kernel.org/...c/d7af6eee8cd60f55aa8c5fe2b91f11ec0c9a0f27
git.kernel.org/...c/e26268ff1dcae5662c1b96c35f18cfa6ab73d9de
Support options
