CVE-2021-47004

What it actually does

Improper validation of checkpointed blocks when selecting victim segments for garbage collection in f2fs checkpoint-disabled mode allows LFS or SSR/AT_SSR allocators to pick segments containing both checkpointed and newly written data, resulting in invalid free-space accounting, kernel panic, or filesystem corruption during subsequent allocations.

Why it matters to the business

Systems using f2fs with checkpoint disabling may experience unexpected crashes or silent data corruption during normal write and garbage-collection activity, increasing downtime and recovery costs.

How an attack unfolds

An attacker with local write access triggers repeated garbage-collection cycles under checkpoint-disabled mode while the filesystem is near capacity; the flawed victim selector picks a partially checkpointed segment, GC migrates blocks into it, and a later SSR allocation attempt then writes over checkpointed data, causing panic or corruption.

How to fix it

Apply the upstream kernel patch that corrects the section-level checkpoint-block check and prevents selection of segments containing checkpointed data; rebuild and reboot with the fixed kernel.

How to confirm the fix worked

Confirm the fix is present by inspecting the get_victim() logic for the corrected checkpoint-block count at section granularity and by running filesystem stress tests under checkpoint-disabled mode without observing panic or corruption.

Typical attack path

1. Mount f2fs filesystem with checkpoint disabled
2. Drive filesystem near capacity to force frequent GC
3. Trigger LFS or SSR victim selection in get_victim()
4. GC migrates blocks into a segment still containing checkpointed data
5. Subsequent allocation selects the corrupted segment and panics or corrupts data

How to detect it

Search kernel logs and f2fs debug output for panic strings or allocation failures mentioning get_victim, checkpointed blocks, or SSR victim selection; examine f2fs garbage-collection traces for repeated selection of segments that still contain valid checkpoint blocks.

What your security team should do

• Identify all Linux systems running f2fs with checkpoint_disabled mount option
• Prioritize patching those systems to the fixed kernel version
• Temporarily avoid checkpoint-disabled mode on unpatched kernels if feasible
• Monitor kernel logs for f2fs panic messages indicating victim-selection failures