CVE-2026-23267: Linux Kernel Race Condition Vulnerability

CVE-2026-23267 Overview

A race condition vulnerability has been identified in the Linux kernel's F2FS (Flash-Friendly File System) subsystem. The issue stems from an IS_CHECKPOINTED flag inconsistency caused by concurrent atomic commit and checkpoint write operations. During Sudden Power Off (SPO) testing, when mounting F2FS, an -EINVAL error was returned from f2fs_recover_inode_page due to improper synchronization between threads performing atomic file sync operations and checkpoint writes.

Critical Impact

This vulnerability can cause filesystem inconsistencies and mount failures after unexpected power loss events, potentially leading to data integrity issues on systems using F2FS.

Affected Products

• Linux kernel with F2FS filesystem support
• Systems utilizing F2FS atomic write operations
• Flash storage devices with F2FS formatting

Discovery Timeline

• 2026-03-18 - CVE-2026-23267 published to NVD
• 2026-03-19 - Last updated in NVD database

Technical Details for CVE-2026-23267

Vulnerability Analysis

This vulnerability manifests as a race condition between two concurrent threads executing F2FS filesystem operations. The issue occurs when Thread A performs f2fs_ioc_commit_atomic_write while Thread B concurrently executes f2fs_write_checkpoint. The timing window between folio_lock(last_folio) scheduling and checkpoint operations creates a state where the IS_CHECKPOINTED flag in the nat_entry structure becomes inconsistent with the actual checkpoint state.

When Thread A calls f2fs_need_dentry_mark(sbi, ino), the last_folio has already been written once by Thread B's checkpoint operation. However, because the {struct nat_entry}->flag did not have the IS_CHECKPOINTED bit set at the critical check point, Thread A proceeds to call set_dentry_mark(last_folio, 1) and writes the folio again after Thread B has completed f2fs_write_checkpoint. This results in a post-SPO state where {struct node_info}->blk_addr is not NULL_ADDR because Thread B's checkpoint was successfully written, but the filesystem metadata is inconsistent.

Root Cause

The root cause lies in insufficient locking during atomic file fsync operations. The sbi->node_write semaphore is acquired too late in the __write_node_folio path, creating a window where the checkpoint operation can complete and set the IS_CHECKPOINTED flag while the atomic write thread is still holding stale state information. For regular file fsync operations, the folio must be dirty and the checkpoint process waits for dirty node page submissions to complete. However, atomic write scenarios bypass this safeguard, allowing the race condition to manifest.

Attack Vector

This vulnerability is triggered by specific internal filesystem operations during concurrent atomic commits and checkpoint writes. The attack vector is local and requires the ability to perform filesystem operations on an F2FS-mounted volume. While not directly exploitable for code execution, the race condition can cause filesystem corruption and denial of service through mount failures.

The vulnerability condition occurs when:

1. An atomic write operation initiates f2fs_do_sync_file with atomic flag set
2. A concurrent checkpoint operation executes block_operations and writes back the folio
3. The atomic write thread schedules before acquiring folio_lock, allowing the checkpoint to proceed
4. The checkpoint sets IS_CHECKPOINTED flag in NAT entries
5. The atomic write thread then writes the folio again with incorrect dentry marks
6. A sudden power off occurs, leaving the filesystem in an inconsistent state

Detection Methods for CVE-2026-23267

Indicators of Compromise

• F2FS mount failures with -EINVAL error from f2fs_recover_inode_page
• Kernel log messages indicating NAT entry or checkpoint inconsistencies
• Unexpected filesystem recovery triggers after normal shutdowns
• Corruption detected in atomic write files after power events

Detection Strategies

• Monitor kernel logs for F2FS recovery errors during mount operations
• Implement filesystem integrity checks after unexpected power loss events
• Track atomic write operations and checkpoint timing through kernel tracing
• Use dmesg filtering for F2FS-related error messages

Monitoring Recommendations

• Enable F2FS debug logging to capture checkpoint and atomic write operation timing
• Implement automated filesystem consistency checks in boot scripts for F2FS volumes
• Deploy kernel event monitoring for race condition indicators in the F2FS subsystem

How to Mitigate CVE-2026-23267

Immediate Actions Required

• Apply the latest Linux kernel patches containing the F2FS fix
• Consider temporarily avoiding atomic write operations on critical F2FS volumes
• Ensure proper UPS or power protection for systems using F2FS with atomic writes
• Schedule maintenance windows to update affected kernel versions

Patch Information

The Linux kernel development team has released patches across multiple stable branches to address this vulnerability. The fix ensures that for atomic file fsync operations, sbi->node_write is acquired through __write_node_folio to guarantee the IS_CHECKPOINTED flag correctly indicates checkpoint write completion status.

Patches are available through the following kernel commits:

• Linux Kernel Commit 32bc3c9
• Linux Kernel Commit 75e19da
• Linux Kernel Commit 7633a73
• Linux Kernel Commit 962c167
• Linux Kernel Commit bd66b4c
• Linux Kernel Commit ed81bc5

Workarounds

• Avoid using atomic write operations on F2FS filesystems until patched
• Implement application-level data integrity checks for critical data on F2FS volumes
• Consider using alternative filesystems (ext4, XFS) for workloads requiring atomic write semantics
• Deploy power protection systems to minimize SPO events on affected systems

# Check current kernel version for F2FS support
uname -r

# View F2FS mount status and options
mount | grep f2fs

# Check kernel logs for F2FS errors
dmesg | grep -i f2fs

# Update kernel packages (Debian/Ubuntu)
sudo apt update && sudo apt upgrade linux-image-generic