Linux Kernel, Logical Flaw, CVE-2026-23233 (Severity unknown)

Listen to this Post

CVE-2026-23233 is a logical flaw in the Linux kernel’s F2FS (Flash-Friendly File System) discovered by Xiaolong Guo. The vulnerability resides in the `check_swap_activate()` function within `fs/f2fs/data.c` and affects kernel versions 6.6 and later . The issue manifests when a swapfile is smaller than the F2FS section size (2MB) and has a fragmented physical layout with multiple non-contiguous extents . When the first extent of such a swapfile is not aligned to the section boundaries, the function’s error handling logic misfires. Specifically, after rounding up the number of blocks (nr_pblocks) to the section size, the code checks if this value exceeds the swapfile’s maximum size (sis->max). If it does, it subtracts a section’s worth of blocks, which can result in `nr_pblocks` becoming zero . The code then incorrectly interprets this zero value as an indicator that the current extent is the last one in the file . It sets `nr_pblocks` to cover the remainder of the swapfile and performs block migration. Critically, after this migration, the function fails to retry the mapping process for the subsequent extents . Consequently, only the first extent is mapped in the `swap_extent` list, causing all swap I/O to be directed to the physical blocks of that first extent, overwriting the wrong locations on disk and corrupting data belonging to other files .

dailycve form:

Platform: Linux Kernel
Version: 6.6 and later
Vulnerability : Logical Flaw
Severity: Unknown
date: March 4, 2026

Prediction: Patched March 2026

What Undercode Say:

Analytics:

This vulnerability is triggered under a precise set of conditions, making it a subtle but severe data corruption issue. The flaw was introduced in kernel version 6.6, while version 6.1 remains unaffected . It is specific to the F2FS filesystem and does not impact ext4 . The root cause is an incorrect assumption in the error-handling path of check_swap_activate(), where a calculated value of zero for `nr_pblocks` is treated as a marker for the last extent, rather than a sign of a boundary condition that requires a different handling approach. The provided fix, implemented by Chao Yu, modifies the logic to ensure that block mapping information is looked up again after all blocks in the tail of the swapfile have been migrated, ensuring all extents are properly processed .

Bash commands and code related to the blog

Steps to Reproduce the Vulnerability (as per )
1. Setup a device with an F2FS-formatted partition (e.g., /dev/sdb1 mounted at /mnt/f2fs_test)
2. Create a small, fragmented swapfile (< 2MB)
fallocate -l 1M /mnt/f2fs_test/swapfile
chmod 600 /mnt/f2fs_test/swapfile
3. Make the swapfile fragmented (example: write in parts, this is conceptual)
dd if=/dev/zero of=/mnt/f2fs_test/swapfile bs=4k count=128 conv=notrunc
dd if=/dev/zero of=/mnt/f2fs_test/swapfile bs=4k seek=200 count=56 conv=notrunc
4. Initialize and turn on the swapfile
mkswap /mnt/f2fs_test/swapfile
swapon /mnt/f2fs_test/swapfile
5. Run a swap stress test
stress-ng --swap 1 --timeout 60s

Code (The Fix):

The patch modifies the conditional block in `fs/f2fs/data.c` to correctly handle the retry logic after block migration .

// In fs/f2fs/data.c within the check_swap_activate() function
// ... (previous code)
// The vulnerable code block is replaced with logic that always retries
// after migrating unaligned blocks, ensuring subsequent extents are mapped.
if (!last_extent &&
((pblock - SM_I(sbi)->main_blkaddr) % blks_per_sec ||
nr_pblocks % blks_per_sec ||
f2fs_is_sequential_zone_area(sbi, pblock))) {
not_aligned++;
nr_pblocks = roundup(nr_pblocks, blks_per_sec);
if (cur_lblock + nr_pblocks > sis->max)
nr_pblocks -= blks_per_sec;
// ... (migration code) ...
/ lookup block mapping info after block migration /
goto retry; // This ensures the loop re-attempts mapping for the same logical block after migration.
}
// ... (rest of the function)

How Exploit:

An attacker with the ability to create files and enable swap on an F2FS filesystem could potentially trigger this bug to cause data corruption. The exploit scenario is not about gaining code execution but about causing a denial of service or corrupting sensitive data. By crafting a swapfile that meets the specific criteria (size < 2MB, fragmented, first extent unaligned) and then inducing heavy swap activity (e.g., via a memory pressure tool like stress-ng), the kernel will activate the swapfile. The flawed mapping logic will then cause swap writes to land on physical blocks belonging to other, unrelated files, corrupting them . This could lead to system instability, file system corruption, and in the case of dm-verity protected partitions, device reboots .

Protection from this CVE:

  1. Apply Patch: Update the Linux kernel to a version containing the fix. Fixed versions include 6.6.127, 6.12.74, 6.18.13, and 7.0-rc1 or later .
  2. Use Larger Swapfiles: Avoid creating swapfiles smaller than the F2FS section size (typically 2MB). Create swapfiles larger than 2MB to bypass the vulnerable code path .
  3. Use Contiguous Swapfiles: When creating a swapfile on F2FS, ensure it is allocated in a contiguous manner using `fallocate` with the `-l` flag, rather than creating a sparse file .
    fallocate -l 4M /path/to/swapfile
    chmod 600 /path/to/swapfile
    mkswap /path/to/swapfile
    swapon /path/to/swapfile
    
  4. Use ext4: Temporarily use a different filesystem like ext4 for swap partitions or files, as it is unaffected by this specific bug .
  5. Disable Swap: As a last resort, disable swap on F2FS filesystems if patching is not immediately possible and data integrity is critical.

Impact:

Successful exploitation of CVE-2026-23233 leads to data corruption on the F2FS filesystem. This can manifest in several severe ways:
– dm-verity Corruption: On systems using dm-verity for integrity checking (common in Android), corrupted data blocks will cause verification failures, leading to device reboots .
– F2FS Node Corruption: Overwriting critical filesystem structures can lead to F2FS node corruption, resulting in boot hangs and an unusable system .
– Silent Data Corruption: Swap writes can overwrite the data of other, unrelated files, leading to unpredictable application behavior and potential loss of user data .

🎯Let’s Practice Exploiting & Learn Patching For Free:

Sources:

Reported By: nvd.nist.gov
Extra Source Hub:
Undercode

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow DailyCVE & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin Featured Image

Scroll to Top