CVE-2025-38220 The advisory has been revoked - it doesn't affect any version of package kernel-headers (opens in a new tab)
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk IDSNYK-CENTOS6-KERNELHEADERS-10644250
- published6 Jul 2025
- disclosed4 Jul 2025
Introduced: 4 Jul 2025
NewCVE-2025-38220 (opens in a new tab)Amendment
The Centos security team deemed this advisory irrelevant for Centos:6.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-headers package and not the kernel-headers package as distributed by Centos.
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.
References
- https://access.redhat.com/security/cve/CVE-2025-38220
- https://git.kernel.org/stable/c/be5f3061a6f904e3674257879e71881ceee5b673
- https://git.kernel.org/stable/c/cf6a4c4ac7b6e3214f25df594c9689a62f1bb456
- https://git.kernel.org/stable/c/d7af6eee8cd60f55aa8c5fe2b91f11ec0c9a0f27
- https://git.kernel.org/stable/c/e26268ff1dcae5662c1b96c35f18cfa6ab73d9de