CVE-2026-23233 in Linux
Summary
by MITRE • 03/04/2026
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to avoid mapping wrong physical block for swapfile
Xiaolong Guo reported a f2fs bug in bugzilla [1]
[1] https://bugzilla.kernel.org/show_bug.cgi?id=220951
Quoted:
"When using stress-ng's swap stress test on F2FS filesystem with kernel 6.6+, the system experiences data corruption leading to either: 1 dm-verity corruption errors and device reboot 2 F2FS node corruption errors and boot hangs
The issue occurs specifically when: 1 Using F2FS filesystem (ext4 is unaffected) 2 Swapfile size is less than F2FS section size (2MB) 3 Swapfile has fragmented physical layout (multiple non-contiguous extents) 4 Kernel version is 6.6+ (6.1 is unaffected)
The root cause is in check_swap_activate() function in fs/f2fs/data.c. When the first extent of a small swapfile (< 2MB) is not aligned to section boundaries, the function incorrectly treats it as the last extent, failing to map subsequent extents. This results in incorrect swap_extent creation where only the first extent is mapped, causing subsequent swap writes to overwrite wrong physical locations (other files' data).
Steps to Reproduce 1 Setup a device with F2FS-formatted userdata partition 2 Compile stress-ng from https://github.com/ColinIanKing/stress-ng 3 Run swap stress test: (Android devices) adb shell "cd /data/stressng; ./stress-ng-64 --metrics-brief --timeout 60 --swap 0"
Log: 1 Ftrace shows in kernel 6.6, only first extent is mapped during second f2fs_map_blocks call in check_swap_activate(): stress-ng-swap-8990: f2fs_map_blocks: ino=11002, file offset=0, start blkaddr=0x43143, len=0x1 (Only 4KB mapped, not the full swapfile) 2 in kernel 6.1, both extents are correctly mapped: stress-ng-swap-5966: f2fs_map_blocks: ino=28011, file offset=0, start blkaddr=0x13cd4, len=0x1 stress-ng-swap-5966: f2fs_map_blocks: ino=28011, file offset=1, start blkaddr=0x60c84b, len=0xff
The problematic code is in check_swap_activate(): if ((pblock - SM_I(sbi)->main_blkaddr) % blks_per_sec || nr_pblocks % blks_per_sec || !f2fs_valid_pinned_area(sbi, pblock)) {
bool last_extent = false;
not_aligned++;
nr_pblocks = roundup(nr_pblocks, blks_per_sec); if (cur_lblock + nr_pblocks > sis->max) nr_pblocks -= blks_per_sec;
/* this extent is last one */ if (!nr_pblocks) {
nr_pblocks = last_lblock - cur_lblock; last_extent = true; }
ret = f2fs_migrate_blocks(inode, cur_lblock, nr_pblocks); if (ret) {
if (ret == -ENOENT) ret = -EINVAL; goto out; }
if (!last_extent) goto retry; }
When the first extent is unaligned and roundup(nr_pblocks, blks_per_sec) exceeds sis->max, we subtract blks_per_sec resulting in nr_pblocks = 0. The code then incorrectly assumes this is the last extent, sets nr_pblocks = last_lblock - cur_lblock (entire swapfile), and performs migration. After migration, it doesn't retry mapping, so subsequent extents are never processed. "
In order to fix this issue, we need to lookup block mapping info after we migrate all blocks in the tail of swapfile.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 06/24/2026
The vulnerability CVE-2026-23233 represents a critical flaw in the Linux kernel's F2FS filesystem implementation that specifically affects swap file handling. This issue manifests as data corruption during swap operations on F2FS filesystems with kernel versions 6.6 and higher, where the system experiences either dm-verity corruption errors leading to device reboots or F2FS node corruption errors causing boot hangs. The root cause lies within the check_swap_activate() function in fs/f2fs/data.c, which incorrectly processes swap file extents when the first extent of a small swapfile (less than 2MB) is not aligned to section boundaries. This misalignment triggers a flawed logic path where the function treats the first extent as if it were the last extent, thereby failing to map subsequent extents properly.
The technical flaw occurs when the function encounters an unaligned first extent of a swapfile smaller than the F2FS section size of 2MB. The problematic code path involves checking if the physical block address is aligned to section boundaries and if the number of physical blocks is aligned to section boundaries. When these conditions fail, the code attempts to round up the number of physical blocks to section boundaries and then performs calculations that result in nr_pblocks being set to zero. This zero value incorrectly triggers the logic that assumes this is the final extent, leading to a complete swapfile mapping operation that overwrites physical locations intended for other files. The vulnerability is particularly severe because it affects the core swap functionality of the operating system, potentially causing system instability and data loss. This flaw demonstrates poor handling of boundary conditions in filesystem block mapping operations and represents a clear violation of proper resource management principles.
The operational impact of this vulnerability extends beyond simple system instability to potentially catastrophic data corruption scenarios that could affect entire system boot processes and data integrity. When the system attempts to perform swap operations, the incorrect block mapping causes subsequent write operations to overwrite legitimate data blocks, leading to filesystem corruption that can manifest as dm-verity verification failures or F2FS node corruption. The vulnerability is specifically triggered in environments using F2FS filesystems with swapfiles smaller than 2MB that have fragmented physical layouts, making it particularly relevant for mobile devices and embedded systems where such configurations are common. The fact that this issue only affects kernel versions 6.6+ while 6.1 remains unaffected indicates a regression introduced in the codebase, likely during recent optimization or refactoring efforts. This vulnerability directly impacts system reliability and could be exploited by malicious actors to cause persistent system instability or data corruption.
The fix for this vulnerability requires modifying the check_swap_activate() function to properly handle the case where block mapping information must be looked up after all blocks in the tail of the swapfile have been migrated. This approach ensures that subsequent extents are properly mapped and processed rather than incorrectly assuming the current extent is the final one. The solution involves restructuring the logic flow to prevent the premature assumption that a zero nr_pblocks value indicates the last extent, instead requiring proper block mapping verification after migration operations. This fix aligns with established security practices for filesystem implementations and follows the principle of least privilege by ensuring that all block mapping operations are properly validated before proceeding with subsequent operations. The vulnerability demonstrates the importance of careful boundary condition handling in kernel code and the critical need for comprehensive testing of filesystem operations under various configuration scenarios, particularly those involving swap functionality and block alignment requirements. This issue maps to CWE-129 and CWE-787 within the Common Weakness Enumeration framework, representing weaknesses in input validation and buffer overflow protection. The ATT&CK framework categorizes this vulnerability under T1490 (Inhibit System Recovery) and T1070 (Indicator Removal on Host) due to its potential to cause system instability and data corruption that could mask other security incidents.