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.
Published: 2026-03-04
Score: 7.8 High
EPSS: < 1% Very Low
KEV: No
Impact: Data corruption leading to system reboot or boot hang
Action: Apply Kernel Update
AI Analysis

Impact

In the Linux kernel, the f2fs filesystem contains a bug that causes swapfiles smaller than the filesystem section size (2 MB) and with fragmented layouts to be mapped incorrectly. The buggy logic in check_swap_activate() incorrectly treats the first unaligned extent as the last one, resulting in only the first portion of the swapfile being mapped. Subsequent swap writes then overwrite unrelated data on the underlying storage, corrupting application data, the f2fs metadata, or kernel memory. This corruption can trigger dm‑verity errors that reboot the device or cause the kernel to hang during boot.

Affected Systems

The vulnerability affects all platforms running Linux kernel versions 6.6 and later when an F2FS filesystem is used as the swap pool. The issue is exposed only when the swapfile is smaller than 2 MB and has multiple non‑contiguous extents; it does not affect ext4 or other filesystems. Devices using Android (which commonly mount f2fs for userdata) are especially susceptible because the bug was discovered during a stress‑ng swap test on that environment. The patch is present in kernel releases after the commit that fixed the mapping logic, but older 6.6 snapshots prior to the fix remain vulnerable.

Risk and Exploitability

The vulnerability is rated CVSS 7.8, indicating high severity, but the EPSS score is below 1 % and the issue is not listed in CISA’s KEV catalog, implying a low likelihood of widespread exploitation. The attack vector requires local access to control swapfile creation and requires the victim’s system to be using f2fs with a small, fragmented swapfile. An attacker who can influence these conditions could cause data corruption, leading to loss of integrity, possible reboot, or boot hang. The exploit would operate silently until the corruption is detected by the system or by users observing failures.

Generated by OpenCVE AI on April 15, 2026 at 15:43 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Upgrade Linux kernel to a version that includes the f2fs swap mapping fix (patches available in kernel 6.6+ after the commit).
  • Replace or reconfigure the swapfile on F2FS volumes to be larger than 2 MB and non‑fragmented, or migrate swap to a different filesystem such as ext4.
  • If immediate kernel upgrade is not feasible, disable swap on the F2FS partition or unmount the filesystem to prevent further corruption.

Generated by OpenCVE AI on April 15, 2026 at 15:43 UTC.

Tracking

Sign in to view the affected projects.

Advisories
Source ID Title
Debian DSA Debian DSA DSA-6162-1 linux security update
History

Tue, 17 Mar 2026 21:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-787
Metrics cvssV3_1

{'score': 7.8, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H'}


Thu, 05 Mar 2026 00:15:00 +0000


Wed, 04 Mar 2026 14:45:00 +0000

Type Values Removed Values Added
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.
Title f2fs: fix to avoid mapping wrong physical block for swapfile
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-04-13T06:02:50.362Z

Reserved: 2026-01-13T15:37:45.988Z

Link: CVE-2026-23233

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Analyzed

Published: 2026-03-04T15:16:13.603

Modified: 2026-03-17T21:21:30.687

Link: CVE-2026-23233

cve-icon Redhat

Severity :

Publid Date: 2026-03-04T00:00:00Z

Links: CVE-2026-23233 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-04-15T17:00:07Z

Weaknesses