AZL-64767
See a problem?- 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:23.777709Z
- 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: <TASK> ext4blockzeropagerange+0x30c/0x380 [ext4] ext4truncate+0x436/0x440 [ext4] ext4processorphan+0x5d/0x110 [ext4] ext4orphancleanup+0x124/0x4f0 [ext4] ext4fillsuper+0x262d/0x3110 [ext4] gettreebdevflags+0x132/0x1d0 vfsgettree+0x26/0xd0 vfscmdcreate+0x59/0xe0 __dosysfsconfig+0x4ed/0x6b0 dosyscall64+0x82/0x170 ...
This occurs when processing a symlink inode from the orphan list. The partial block zeroing code in the truncate path calls ext4dirtyjournalleddata() -> foliomarkdirty(). The latter calls mapping->aops->dirtyfolio(), but symlink inodes are not assigned an aops vector in ext4, hence the crash.
To avoid this problem, update the ext4dirtyjournalleddata() helper to only mark the folio dirty on regular files (for which aops is assigned). This also matches the journaling logic in the ext4symlink() creation path, where ext4handledirtymetadata() is called directly.
- References