CVE-2026-23233

f2fs: fix to avoid mapping wrong physical block for swapfile

published March 4, 2026

CVSS
—
EPSS
0%
Percentile
5.6
In the wild
Unconfirmed
What it is

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.

The record
Technical detail
CVSS
Not scored
CVSS v4.0
Not supplied
EPSS
0.00166 · 5.6th percentile
Published
2026-03-04T14:36Z
EPSS history
Timeline
  • 04 MAR 14:36Z
    f2fs: fix to avoid mapping wrong physical block for swapfile
    cvelistv5