CVE-2021-47406

What it actually does

Missing error handling in ext4_ext_replay_set_iblocks allows ext4_map_blocks failure on a corrupted filesystem (inline_data + fast_commit) to trigger an infinite loop inside ext4_ind_map_blocks and ext4_block_to_path during journal recovery.

Why it matters to the business

Systems may hang during ext4 mount or journal replay, causing extended downtime and requiring manual intervention or reboot; high prevalence of ext4 in servers and containers amplifies operational risk.

How an attack unfolds

An attacker supplies a maliciously crafted ext4 filesystem image containing inline_data and fast_commit metadata; when the kernel performs journal recovery, ext4_fc_replay triggers ext4_ext_replay_set_iblocks, a failing ext4_map_blocks call leads to repeated logging and an unrecoverable tight loop that freezes the system.

How to fix it

Apply the upstream patch that adds error checking inside ext4_ext_replay_set_iblocks; rebuild and deploy a fixed kernel; consider disabling fast_commit on ext4 volumes until the full fast-commit replay error paths are hardened.

How to confirm the fix worked

Confirm the patched function contains an explicit error return from ext4_map_blocks and breaks the loop; re-run fstests generic/526 with inline_data and fast_commit enabled and verify the system no longer hangs.

Typical attack path

1. Prepare ext4 filesystem image with inline_data and fast_commit enabled plus deliberate corruption
2. Cause target to mount the image or replay its journal (e.g., during boot or fsck)
3. ext4_fc_replay_inode calls ext4_ext_replay_set_iblocks
4. ext4_map_blocks fails repeatedly without error propagation
5. Kernel enters infinite loop in ext4_block_to_path / ext4_ind_map_blocks, logging warnings and hanging

How to detect it

Search kernel logs and console output for repeated "EXT4-fs warning" messages containing "block ... > max in inode" together with stack frames naming ext4_ext_replay_set_iblocks, ext4_fc_replay_inode, or jbd2_journal_recover; correlate with mount or boot failures.

• EXT4-fs warning (device
• ext4_block_to_path
• ext4_ext_replay_set_iblocks
• ext4_fc_replay_inode
• skip_hole

What your security team should do

• Prioritize kernel update on all systems using ext4 with fast_commit
• Add monitoring for repeated EXT4-fs block-to-path warnings during mount
• Temporarily disable fast_commit feature on high-value ext4 volumes
• Include ext4 journal-recovery paths in crash-dump and hang analysis playbooks