CVE-2025-71065: Linux Kernel Race Condition Vulnerability

CVE-2025-71065 Overview

A deadlock vulnerability exists in the Linux kernel's f2fs (Flash-Friendly File System) implementation. The issue arises from improper lock ordering between four distinct locks: fs_reclaim, sb_internal, cp_rwsem, and the lock used by f2fs_record_errors. When specific code paths are executed concurrently across multiple CPUs, a circular dependency can form, resulting in a system deadlock that causes denial of service.

Critical Impact

This vulnerability can cause complete system hang through deadlock conditions in the Linux kernel's f2fs filesystem, affecting system availability and requiring a hard reboot to recover.

Affected Products

• Linux kernel with f2fs filesystem support
• Systems using f2fs for storage (common in Android devices and flash storage)
• Linux kernel versions prior to the security patches

Discovery Timeline

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

Technical Details for CVE-2025-71065

Vulnerability Analysis

This vulnerability is a classic deadlock condition caused by circular lock dependencies in the f2fs filesystem driver. The deadlock involves a chain of four locks that can be acquired in conflicting orders across different kernel code paths, specifically involving the checkpoint read-write semaphore (&sbi->cp_rwsem), filesystem reclaim lock (fs_reclaim), and superblock internal lock (sb_internal).

The vulnerability was identified by Jiaming Zhang and reported through the syzbot automated testing framework. The deadlock manifests when the kswapd kernel thread attempts memory reclamation while concurrent filesystem operations are in progress. The specific scenario involves inode eviction (f2fs_evict_inode), block truncation (f2fs_do_truncate_blocks), atomic write commits (f2fs_ioc_commit_atomic_write), and error handling paths (f2fs_record_errors).

Root Cause

The root cause is improper lock ordering across multiple f2fs code paths. Four distinct locks are involved in creating a circular dependency:

1. Lock A (fs_reclaim): Acquired by kswapd during memory pressure scenarios in balance_pgdat
2. Lock B (sb_start_intwrite/sb_internal): Acquired during inode eviction in f2fs_evict_inode
3. Lock C (cp_rwsem via f2fs_lock_op): Acquired during block truncation operations
4. Lock D (f2fs_down_write): Acquired during error recording which may trigger memory allocation

The circular dependency forms when these locks are acquired in different orders across concurrent code paths. For example, kswapd holds fs_reclaim then requests sb_internal, while another CPU holds sb_internal and requests cp_rwsem, creating an unresolvable wait cycle.

Attack Vector

The deadlock can be triggered through normal filesystem operations under memory pressure conditions. The attack vector involves:

1. A system experiencing memory pressure, activating the kswapd kernel thread
2. Concurrent filesystem operations on f2fs-mounted volumes, particularly atomic write commits or file truncation operations
3. Error conditions that trigger the f2fs_handle_error path, which calls f2fs_record_errors

The vulnerability is primarily a denial of service condition. An attacker with local access could potentially craft specific workloads to trigger the deadlock condition, causing the system to hang. This is especially concerning for Android devices where f2fs is commonly used.

The call trace from the syzbot report shows the deadlock occurring through:

• kswapd → shrink_slab → super_cache_scan → prune_icache_sb → f2fs_evict_inode → f2fs_truncate_blocks → f2fs_do_truncate_blocks → f2fs_lock_op

Detection Methods for CVE-2025-71065

Indicators of Compromise

• System hangs or becomes unresponsive while performing f2fs filesystem operations
• Kernel lockdep warnings indicating circular locking dependencies involving f2fs locks
• Process states showing multiple kernel threads in uninterruptible sleep (D state) related to f2fs operations
• Kernel log messages showing "possible circular locking dependency detected" with references to cp_rwsem, fs_reclaim, or sb_internal

Detection Strategies

• Enable kernel lockdep debugging (CONFIG_LOCKDEP=y) to detect potential deadlock scenarios before they occur in production
• Monitor for kernel log entries containing "deadlock" or "circular locking" alongside f2fs-related functions
• Implement watchdog mechanisms to detect and alert on system hangs
• Use SentinelOne's kernel-level monitoring capabilities to detect abnormal lock acquisition patterns

Monitoring Recommendations

• Configure kernel logging to capture lockdep warnings and deadlock detection messages
• Monitor system responsiveness metrics to detect potential deadlock conditions early
• Track f2fs-related kernel process states for unusual patterns of uninterruptible sleep
• Enable audit logging for f2fs mount operations and filesystem activities

How to Mitigate CVE-2025-71065

Immediate Actions Required

• Update the Linux kernel to a patched version that includes the deadlock fix
• Monitor systems using f2fs for signs of system hangs or unresponsiveness
• Consider temporarily switching to alternative filesystems (ext4, xfs) for critical workloads if immediate patching is not possible
• Implement system monitoring and automatic restart mechanisms to recover from potential deadlock conditions

Patch Information

The Linux kernel developers have released patches to address this deadlock vulnerability. The fix modifies the lock acquisition order in the f2fs filesystem driver to prevent the circular dependency from forming. Multiple kernel git commits address this issue:

• Kernel Git Commit 6c3bab5c6261
• Kernel Git Commit 86a85a7b622e
• Kernel Git Commit 8bd6dff8b801
• Kernel Git Commit ca8b201f2854

Organizations should apply these patches or upgrade to a kernel version that includes them as soon as possible.

Workarounds

• Reduce memory pressure on systems using f2fs to minimize the likelihood of triggering the kswapd code path during critical filesystem operations
• Limit concurrent filesystem operations on f2fs volumes where possible
• Configure swap and memory management to reduce aggressive memory reclamation
• For Android devices, consider using ext4 for critical partitions until patches are deployed

# Check current kernel version for patch status
uname -r

# Monitor for deadlock-related kernel messages
dmesg | grep -i "deadlock\|circular"

# Check if f2fs is in use on the system
mount | grep f2fs