CVE-2026-23233
Received Received - Intake
Incorrect Block Mapping Vulnerability in Linux F2FS Swapfile Causes Data Corruption

Publication date: 2026-03-04

Last updated on: 2026-03-17

Assigner: kernel.org

Description
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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-03-04
Last Modified
2026-03-17
Generated
2026-05-07
AI Q&A
2026-03-04
EPSS Evaluated
2026-05-05
NVD
CVE-2026-23233
EUVD
EUVD-2026-9405
Affected Vendors & Products
Showing 4 associated CPEs
Vendor Product Version / Range
linux linux_kernel From 6.13 (inc) to 6.18.13 (exc)
linux linux_kernel From 6.19 (inc) to 6.19.3 (exc)
linux linux_kernel From 6.6.33 (inc) to 6.6.127 (exc)
linux linux_kernel From 6.9 (inc) to 6.12.74 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-787 The product writes data past the end, or before the beginning, of the intended buffer.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability exists in the Linux kernel's f2fs filesystem when using a swapfile smaller than 2MB with a fragmented physical layout on kernel versions 6.6 and above. The issue arises because the function check_swap_activate() incorrectly maps only the first extent of the swapfile if it is not aligned to section boundaries, treating it as the last extent. This causes subsequent extents to be unmapped, leading to incorrect swap writes that overwrite other files' data.

The problem manifests as data corruption, including dm-verity corruption errors and device reboots or F2FS node corruption errors causing boot hangs. The root cause is a logic error in how the kernel rounds up block counts and decides when an extent is the last one, resulting in incomplete mapping of the swapfile's physical blocks.


How can this vulnerability impact me? :

This vulnerability can lead to serious data corruption on devices using the affected Linux kernel versions with the f2fs filesystem and a small fragmented swapfile. The corruption can cause system instability such as device reboots, boot hangs, and loss or overwriting of data belonging to other files.

In practical terms, this means that systems relying on swapfiles under these conditions may experience unexpected crashes or become unbootable, potentially resulting in data loss and downtime.


How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

I don't know


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by observing system behavior when running swap stress tests on an F2FS filesystem with kernel version 6.6 or later. Specifically, running stress-ng's swap stress test can reveal data corruption issues.

A suggested command to reproduce and detect the issue on Android devices is:

  • adb shell "cd /data/stressng; ./stress-ng-64 --metrics-brief --timeout 60 --swap 0"

Additionally, kernel logs (ftrace) can be examined to check if only the first extent of the swapfile is mapped during the f2fs_map_blocks call, which indicates the presence of the vulnerability.


What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation involves avoiding the use of fragmented swapfiles smaller than 2MB on F2FS filesystems with kernel version 6.6 or later.

Upgrading the Linux kernel to a version where this issue is fixed (post 6.6 with the patch applied) is recommended to prevent data corruption caused by incorrect physical block mapping.

Alternatively, using a different filesystem such as ext4 for swapfiles can avoid this issue, as ext4 is unaffected.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart