CVE-2025-38220

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: only dirty folios when data journaling regular files<br /> <br /> fstest generic/388 occasionally reproduces a crash that looks as<br /> follows:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> ...<br /> Call Trace:<br /> <br /> ext4_block_zero_page_range+0x30c/0x380 [ext4]<br /> ext4_truncate+0x436/0x440 [ext4]<br /> ext4_process_orphan+0x5d/0x110 [ext4]<br /> ext4_orphan_cleanup+0x124/0x4f0 [ext4]<br /> ext4_fill_super+0x262d/0x3110 [ext4]<br /> get_tree_bdev_flags+0x132/0x1d0<br /> vfs_get_tree+0x26/0xd0<br /> vfs_cmd_create+0x59/0xe0<br /> __do_sys_fsconfig+0x4ed/0x6b0<br /> do_syscall_64+0x82/0x170<br /> ...<br /> <br /> This occurs when processing a symlink inode from the orphan list. The<br /> partial block zeroing code in the truncate path calls<br /> ext4_dirty_journalled_data() -&gt; folio_mark_dirty(). The latter calls<br /> mapping-&gt;a_ops-&gt;dirty_folio(), but symlink inodes are not assigned an<br /> a_ops vector in ext4, hence the crash.<br /> <br /> To avoid this problem, update the ext4_dirty_journalled_data() helper to<br /> only mark the folio dirty on regular files (for which a_ops is<br /> assigned). This also matches the journaling logic in the ext4_symlink()<br /> creation path, where ext4_handle_dirty_metadata() is called directly.