Listen to this Post
The vulnerability arises from a flawed patch (commit 196c81fdd438) in the Linux kernel’s F2FS (Flash-Friendly File System) filesystem, which was intended to block cache/direct I/O writes during checkpoint enablement. This patch inadvertently introduced a classic deadlock scenario due to improper lock ordering. The deadlock occurs when two concurrent operations—a write operation and a filesystem remount operation—attempt to acquire locks in reverse order. Specifically, a write operation (via write_begin) first locks a page (Lock A). It then proceeds to prepare the write, which requires acquiring a read lock on the checkpoint enable semaphore `cp_enable_rwsem` (Lock B). Simultaneously, a remount operation calls f2fs_enable_checkpoint, which acquires a write lock on the same semaphore `cp_enable_rwsem` (Lock B). While holding this lock, it attempts to sync the inode by calling writepages, which then tries to lock the very same page (Lock A) that the first operation has already locked. This creates a circular dependency: the write holds Lock A and waits for Lock B, while the remount holds Lock B and waits for Lock A. The kernel cannot resolve this deadlock, causing the system to hang. The official fix is to revert the problematic patch entirely, restoring the previous lock behavior to eliminate the condition .
dailycve form:
Platform: Linux Kernel
Version: Up to 6.19.2
Vulnerability : F2FS deadlock
Severity: Critical
date: 2026-03-04
Prediction: Patched (2026-03-03)
What Undercode Say:
Analytics:
The vulnerability is a local denial-of-service (deadlock) issue. Analysis shows it exists in the F2FS subsystem and was introduced by a specific commit aimed at improving checkpoint operations. The revert commit is `b6382273801bc7c778545dd8004c9a9d750b4f62` or 3996b70209f145bfcf2afc7d05dd92c27b233b48. The attack vector requires local system access, making it less severe for cloud environments but critical for multi-user systems or hosts where untrusted users can trigger filesystem operations. The CVSS score from third-party analysts is estimated around 4.8 (Medium), but the functional impact is a system hang, warranting a “Critical” severity in operational contexts .
Bash Commands and Code:
Check current kernel version uname -r Verify if the F2FS module is loaded lsmod | grep f2fs Check for hung tasks in kernel logs (indicators of deadlock) sudo dmesg -T | grep -i "blocked for more than" | grep f2fs List mounted F2FS filesystems mount -t f2fs Example of applying the patch (if compiling manually) wget https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/patch/?id=b6382273801bc7c778545dd8004c9a9d750b4f62 git am b6382273801bc7c778545dd8004c9a9d750b4f62.patch To enable kernel lock debugging (if rebuilding kernel) CONFIG_DEBUG_LOCK_ALLOC=y CONFIG_PROVE_LOCKING=y
How Exploit:
- An attacker with local user access mounts an F2FS filesystem.
- The attacker initiates a heavy write operation to a file on this mount (e.g.,
dd if=/dev/zero of=/mnt/f2fs_test/file bs=1M count=1000 &). - Simultaneously, the attacker (or a process) triggers a remount operation that enables checkpointing (e.g.,
mount -o remount,checkpoint=enable /mnt/f2fs_test). - The kernel thread handling the remount attempts to sync the inode and write pages, colliding with the page lock held by the writing process.
- Both processes enter an uninterruptible sleep state (D-state), causing the F2FS operations to hang indefinitely, leading to a denial of service .
Protection from this CVE:
- Patch the Kernel: Update to a kernel version that includes the revert commit (versions > 6.19.2 or 7.0-rc1). This is the primary fix.
- Distribution Updates: Apply updates from your Linux distribution as soon as they release patched kernels (e.g., Ubuntu, Red Hat).
- Workaround: Avoid performing remount operations on F2FS filesystems while intensive write I/O is in progress. Schedule maintenance windows for filesystem reconfigurations.
- Alternative FS: For critical systems where availability is paramount and untrusted users exist, consider using mature filesystems like ext4 or XFS until the patched kernel is deployed .
Impact:
A successful exploit leads to a complete deadlock of the F2FS subsystem. This results in a denial of service (DOS) for all processes attempting to access the filesystem, potentially freezing the entire system or making it unresponsive. There is no risk of data corruption or privilege escalation directly from this CVE, but the hang may lead to unsaved data loss if a hard reset is required to recover the system .
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: nvd.nist.gov
Extra Source Hub:
Undercode
