CVE-2025-71069: Linux Kernel F2FS Cache Vulnerability

CVE-2025-71069 Overview

CVE-2025-71069 is a vulnerability in the Linux kernel's F2FS (Flash-Friendly File System) component that affects the handling of dentry cache during failed whiteout creation operations. The flaw occurs when RENAME_WHITEOUT operations are performed on directories with corrupted directory depth values, leading to inconsistencies between the on-disk state and the VFS dentry cache.

When f2fs_add_link fails during a whiteout creation operation, the function returns an error to VFS after partial directory modifications have already been committed to disk. VFS assumes the entire rename operation failed and does not update the dentry cache, leaving stale mappings that point to freed inodes. This cache inconsistency can trigger kernel warnings and potentially lead to system instability.

Critical Impact

Stale dentry cache entries can cause subsequent file operations to incorrectly reference freed inodes, triggering drop_nlink() warnings and potential system instability on systems using F2FS filesystems.

Affected Products

• Linux kernel with F2FS filesystem support
• Systems using F2FS filesystems with corrupted directory structures
• Linux distributions shipping affected kernel versions

Discovery Timeline

• 2026-01-13 - CVE CVE-2025-71069 published to NVD
• 2026-01-13 - Last updated in NVD database

Technical Details for CVE-2025-71069

Vulnerability Analysis

This vulnerability stems from a Time-of-Check Time-of-Use (TOCTOU) race condition pattern in the F2FS rename operation handling. The F2FS filesystem allows mounting of filesystems with corrupted i_current_depth values, which get runtime-clamped to MAX_DIR_HASH_DEPTH. This creates a hidden condition where subsequent operations may fail unexpectedly.

The core issue manifests when the f2fs_rename function performs a RENAME_WHITEOUT operation. The function modifies directory entries in a specific sequence: it updates the target entry, deletes the source entry, and then attempts to add the whiteout entry via f2fs_add_link. If the f2fs_add_link call fails due to the corrupted directory structure, the error is returned to VFS, but the partial modifications have already been persisted to disk.

VFS, upon receiving the error, does not invoke d_move() to update the dentry cache. This leaves new_dentry pointing to the old inode (new_inode) that has already had its i_nlink decremented to zero. Subsequent rename operations targeting the same entry attempt to decrement i_nlink on an inode that already has i_nlink=0, triggering a kernel WARNING in the drop_nlink() function.

Root Cause

The root cause is the lack of dentry cache invalidation in the error handling path of f2fs_rename when f2fs_add_link fails during whiteout creation. The function commits partial directory modifications to disk before attempting operations that may fail, without implementing proper rollback or cache synchronization mechanisms when those subsequent operations fail.

The corrupted i_current_depth value in the filesystem metadata triggers the failure in f2fs_add_link, but the fundamental issue is that F2FS does not maintain transactional consistency between the on-disk state and the VFS dentry cache during partial failure scenarios.

Attack Vector

An attacker with local filesystem access could potentially exploit this vulnerability by:

1. Creating or mounting an F2FS filesystem image with a corrupted i_current_depth value
2. Performing a renameat2() system call with the RENAME_WHITEOUT flag on files within the corrupted directory
3. Performing subsequent rename operations targeting the same entry
4. Triggering the drop_nlink() WARNING and potentially causing system instability

The attack requires local access and the ability to mount F2FS filesystems or operate on pre-corrupted F2FS images. The reproduction sequence involves:

1. Mount F2FS image with corrupted i_current_depth
2. Execute renameat2(file2, file1, RENAME_WHITEOUT)
3. Execute renameat2(file3, file1, 0)
4. System triggers WARNING in drop_nlink()

Detection Methods for CVE-2025-71069

Indicators of Compromise

• Kernel warning messages containing drop_nlink() function references in system logs
• F2FS filesystem errors or warnings during rename operations with RENAME_WHITEOUT flag
• Unexpected behavior during file operations on F2FS-mounted filesystems
• Corrupted directory structures detected during F2FS filesystem checks

Detection Strategies

• Monitor kernel logs (dmesg, /var/log/kern.log) for WARNING messages related to drop_nlink() or F2FS rename operations
• Audit renameat2() system calls with RENAME_WHITEOUT flag on F2FS filesystems using kernel tracing tools
• Implement filesystem integrity checks to detect corrupted i_current_depth values in F2FS metadata
• Use security monitoring tools to detect unusual patterns of rename operations targeting the same files

Monitoring Recommendations

• Enable kernel audit logging for filesystem operations on F2FS mounts
• Configure SentinelOne agents to monitor for kernel panic or warning events related to filesystem operations
• Implement periodic F2FS filesystem integrity scans using fsck.f2fs
• Monitor for attempts to mount potentially corrupted F2FS filesystem images

How to Mitigate CVE-2025-71069

Immediate Actions Required

• Update the Linux kernel to a patched version that includes the fix for CVE-2025-71069
• Run filesystem integrity checks on all F2FS filesystems using fsck.f2fs before mounting
• Consider temporarily avoiding use of F2FS filesystems from untrusted sources
• Review system logs for any evidence of exploitation attempts

Patch Information

The fix addresses this vulnerability by explicitly invalidating old_dentry and new_dentry when f2fs_add_link fails during whiteout creation. This forces VFS to refresh from disk on subsequent operations, ensuring cache consistency even when the rename partially succeeds.

Multiple kernel patches have been released to address this issue. The fixes are available via the following kernel Git commits:

• Kernel Git Commit 0dde307
• Kernel Git Commit 3d65e27
• Kernel Git Commit 64587ab
• Kernel Git Commit c89845f
• Kernel Git Commit d33f89b

Workarounds

• Avoid mounting F2FS filesystems from untrusted or potentially corrupted sources
• Use fsck.f2fs to check and repair F2FS filesystems before mounting
• Consider using alternative filesystems (ext4, XFS) for sensitive operations until patches are applied
• Implement strict access controls to limit which users can mount F2FS filesystems

# Check F2FS filesystem integrity before mounting
fsck.f2fs -a /dev/sdX1

# Mount F2FS with read-only option for untrusted sources
mount -t f2fs -o ro /dev/sdX1 /mnt/f2fs

# Check kernel version to verify patch status
uname -r