Import Source
https://github.com/microsoft/AzureLinuxVulnerabilityData/blob/main/osv/AZL-64767.json
JSON Data
https://api.test.osv.dev/v1/vulns/AZL-64767
Upstream
Published
2025-07-04T14:15:30Z
Modified
2026-04-01T05:20:23Z
Summary
CVE-2025-38220 affecting package kernel for versions less than 6.6.96.1-1
Details

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: 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.

References

Affected packages

Azure Linux:3 / kernel

Package

Name
kernel
Purl
pkg:rpm/azure-linux/kernel

Affected ranges

Type
ECOSYSTEM
Events
Introduced
0 Unknown introduced version / All previous versions are affected
Fixed
6.6.96.1-1

Database specific

source
"https://github.com/microsoft/AzureLinuxVulnerabilityData/blob/main/osv/AZL-64767.json"