CVE-2026-23233: Linux Kernel F2FS DOS Vulnerability

CVE-2026-23233 Overview

A vulnerability has been identified in the Linux kernel's F2FS (Flash-Friendly File System) implementation that allows incorrect physical block mapping for swapfiles. The flaw exists in the check_swap_activate() function within fs/f2fs/data.c, where improper handling of unaligned extents causes the kernel to map only the first extent of fragmented swapfiles, leading to swap writes overwriting incorrect physical locations and potentially corrupting other files' data.

This vulnerability can result in data corruption, dm-verity corruption errors requiring device reboot, or F2FS node corruption causing boot hangs. The issue specifically affects systems using F2FS filesystems with swapfiles smaller than the F2FS section size (2MB) that have fragmented physical layouts.

Critical Impact
Data corruption through incorrect swap extent mapping can lead to system instability, dm-verity corruption errors, F2FS node corruption, and potential boot failures on affected Linux systems running kernel 6.6+.

Affected Products

Linux kernel versions 6.6 and later with F2FS filesystem support
Systems using F2FS swapfiles smaller than 2MB (section size)
Android devices with F2FS-formatted userdata partitions

Discovery Timeline

March 4, 2026 - CVE-2026-23233 published to NVD
March 4, 2026 - Last updated in NVD database

Technical Details for CVE-2026-23233

Vulnerability Analysis

The vulnerability is a kernel file system vulnerability affecting the F2FS swapfile activation mechanism. When a swapfile has fragmented physical layout with multiple non-contiguous extents and the first extent is not aligned to section boundaries, the check_swap_activate() function incorrectly identifies it as the last extent. This occurs because when roundup(nr_pblocks, blks_per_sec) exceeds sis->max, the code subtracts blks_per_sec, potentially resulting in nr_pblocks = 0.

When nr_pblocks equals zero, the code assumes this is the last extent, sets nr_pblocks = last_lblock - cur_lblock (covering the entire swapfile), and performs migration. Critically, after this migration, the function does not retry the mapping process, causing subsequent extents to remain unmapped.

The result is incorrect swap_extent creation where only the first extent is properly mapped. Subsequent swap operations write to incorrect physical locations, overwriting data belonging to other files. This behavior was introduced in kernel 6.6, as kernel 6.1 correctly maps all extents.

Root Cause

The root cause lies in the boundary condition handling within check_swap_activate() in fs/f2fs/data.c. The logic flaw occurs when processing swapfiles smaller than the F2FS section size (2MB) with fragmented extents. The code incorrectly uses the nr_pblocks = 0 condition to determine if an extent is the "last extent," without considering that this condition can also be triggered by the rounding calculation when processing the first extent of a small, unaligned swapfile.

The fix requires looking up block mapping information after migrating all blocks in the tail of the swapfile, ensuring all extents are properly processed and mapped regardless of their alignment status.

Attack Vector

This vulnerability can be triggered through normal system operations involving swap stress on F2FS filesystems:

A system must have an F2FS-formatted partition with swap enabled
The swapfile must be smaller than 2MB (F2FS section size)
The swapfile must have a fragmented physical layout with multiple non-contiguous extents
The first extent must not be aligned to section boundaries
Swap operations (especially under stress) will trigger the incorrect block mapping

The vulnerability is primarily a local denial of service and data integrity issue rather than an exploitable remote attack vector. Triggering the vulnerability requires the ability to create swapfiles on F2FS filesystems or run applications that stress swap operations.

Detection Methods for CVE-2026-23233

Indicators of Compromise

dm-verity corruption errors appearing in system logs followed by unexpected device reboots
F2FS node corruption errors causing boot hangs or system instability
Unexpected data corruption on F2FS filesystems with active swap
Ftrace logs showing only single extent mapping during f2fs_map_blocks calls (e.g., only 4KB mapped for swapfiles larger than 4KB)

Detection Strategies

Monitor kernel logs for F2FS-related errors, particularly node corruption or mapping errors
Use ftrace to monitor f2fs_map_blocks calls during swapfile activation and verify multiple extents are being mapped for fragmented swapfiles
Check swapfile sizes and compare against F2FS section size (2MB) to identify potentially affected configurations
Audit systems running kernel 6.6+ with F2FS filesystems that have swap enabled

Monitoring Recommendations

Implement kernel log monitoring for dm-verity and F2FS corruption error messages
Set up alerts for unexpected system reboots on devices with F2FS partitions
Monitor file system integrity checks for corruption patterns associated with swap regions
Deploy runtime verification of swapfile extent mapping during swap activation

How to Mitigate CVE-2026-23233

Immediate Actions Required

Update the Linux kernel to a patched version that includes the fix for CVE-2026-23233
If immediate patching is not possible, consider using swapfiles larger than 2MB on F2FS filesystems
Temporarily disable swap on F2FS filesystems if data integrity is critical and patching cannot be performed immediately
Switch to ext4 or other unaffected filesystems for swap storage if F2FS patching is delayed

Patch Information

Multiple kernel patches have been released to address this vulnerability. The fix ensures that block mapping information is looked up after migrating all blocks in the tail of the swapfile, properly handling all extents regardless of alignment.

Patches are available from the following kernel git commits:

Workarounds

Create swapfiles larger than the F2FS section size (2MB) to avoid triggering the vulnerable code path
Ensure swapfiles are created with contiguous physical extents where possible using fallocate before initializing swap
Use ext4 or other filesystems for swap partitions as they are not affected by this vulnerability
On Android devices, avoid running swap stress tests until the kernel is updated

bash

# Configuration example
# Create a swapfile larger than 2MB to avoid the vulnerable code path
fallocate -l 4M /data/swapfile
chmod 600 /data/swapfile
mkswap /data/swapfile

# Alternatively, verify swapfile extent mapping with filefrag
filefrag -v /data/swapfile
# Ensure the swapfile has contiguous extents or is larger than 2MB