CVE-2025-38220

What it actually does

Causes a NULL pointer dereference crash in ext4 during orphan inode cleanup when a symlink inode is processed in data journaling mode, because ext4_dirty_journalled_data calls folio_mark_dirty on an inode lacking an a_ops vector.

Why it matters to the business

Produces kernel panics and unplanned system downtime on Linux deployments using ext4 with data journaling, increasing operational risk across widely deployed kernel versions and downstream packages.

How an attack unfolds

An attacker with local access arranges an ext4 filesystem containing orphaned symlinks under data journaling, then triggers mount or orphan cleanup paths; listed threat actors associated with Linux kernel privilege escalation campaigns may chain or trigger similar memory corruption conditions to achieve denial of service.

How to fix it

Apply the upstream fix in commit cf6a4c4ac7b6e3214f25df594c9689a62f1bb456 or upgrade to a kernel containing that change; for s5cmd packages upgrade Chainguard and Wolfi variants to 2.3.0-r4.

How to confirm the fix worked

Confirm the running kernel contains commit cf6a4c4ac7b6e3214f25df594c9689a62f1bb456, then reproduce generic/388-style fstests or mount a crafted image with orphaned symlinks under data journaling and verify absence of the NULL dereference.

Typical attack path

1. Gain local access to a system with ext4 data journaling enabled
2. Create or manipulate filesystem state to leave symlink inodes on the orphan list
3. Initiate mount or operations invoking ext4_orphan_cleanup
4. Trigger ext4_truncate and ext4_block_zero_page_range on the symlink
5. Cause NULL dereference via missing a_ops in folio_mark_dirty

How to detect it

Inspect kernel logs and dmesg for BUG: kernel NULL pointer dereference traces containing ext4_block_zero_page_range, ext4_truncate, ext4_process_orphan, and ext4_orphan_cleanup; correlate with mount attempts on ext4 volumes using data journaling.

• BUG: kernel NULL pointer dereference, address: 0000000000000000
• ext4_block_zero_page_range+0x30c/0x380
• ext4_truncate+0x436/0x440
• ext4_process_orphan+0x5d/0x110
• ext4_orphan_cleanup+0x124/0x4f0
• ext4_fill_super

What your security team should do

• Immediately schedule kernel updates for all systems using ext4 data journaling given the 480-day exposure window
• Add monitoring for ext4 NULL pointer dereference oops during mount and truncate
• Review and restrict use of data journaling on systems where rapid patching is difficult
• Test the fixed kernel version in staging before broad deployment