CVE-2025-38220

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.

Red Hat rates this vulnerability as Moderate severity because exploitation requires local access or the ability to mount a crafted filesystem, leading to a denial of service via a kernel crash. On standard Red Hat Enterprise Linux installations, mounting filesystems requires elevated administrative privileges, significantly limiting exposure for unprivileged users. Furthermore, Red Hat Enterprise Linux defaults to XFS rather than ext4, restricting the vulnerable footprint to configurations that explicitly mount ext4 storage.

The CVSS score(s) listed for this vulnerability do not reflect the associated product's status, and are included for informational purposes to better understand the severity of this vulnerability.