CVE-2025-38220
Gravedad:
Pendiente de análisis
Tipo:
No Disponible / Otro tipo
Fecha de publicación:
04/07/2025
Última modificación:
04/07/2025
Descripción
*** Pendiente de traducción *** 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() -> folio_mark_dirty(). The latter calls<br />
mapping->a_ops->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.