CVE-2026-23233: f2fs: fix to avoid mapping wrong physical block for swapfile
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.
Security readout for executives and security teams
Plain-English summary
This Linux kernel flaw can corrupt data when swapfiles are used on F2FS under specific layout conditions. Reported impacts include dm-verity errors, reboots, F2FS node corruption, and boot hangs. It is serious for affected Android or embedded-style systems using F2FS swapfiles, but the sources do not show active exploitation.
Executive priority
Treat as a targeted reliability and integrity risk, not a broad internet-exposed emergency. Prioritize fleets where F2FS swapfiles support boot-critical or integrity-checked partitions, because impact can include data corruption and boot failure.
Technical view
The bug is in F2FS swapfile activation. For small, fragmented swapfiles, check_swap_activate() can treat an unaligned first extent as the final extent, create incomplete swap extents, and direct later swap writes to wrong physical blocks. The kernel fix rechecks mapping after migrating tail blocks.
Likely exposure
Exposure appears limited to Linux systems using F2FS-backed swapfiles, especially kernel 6.6+ behavior described in the report, with swapfiles smaller than the F2FS section size and fragmented physical layout. Systems not using F2FS swapfiles are not evidenced as exposed.
Exploitation context
No KEV listing or cited source indicates active exploitation. The public report describes reproducible corruption using a stress workload, not a remote attack path. Local ability to create or exercise the vulnerable swapfile condition appears relevant, but exploit prerequisites are not fully characterized.
Researcher notes
Evidence is strongest for local reproducibility under narrow F2FS swapfile conditions. Version data in the bundle is incomplete and partly commit-oriented, so use upstream stable commits and vendor advisories to map exact affected and fixed releases.
Mitigation direction
Apply a vendor or upstream stable kernel containing the referenced F2FS fix.
Check distribution or device vendor advisories for exact fixed kernel builds.
Avoid F2FS-backed swapfiles on affected kernels where operationally feasible.
Prioritize systems where F2FS swap corruption could break boot integrity.
Test kernel updates against swap and boot workflows before rollout.
Validation and detection
Inventory Linux systems using F2FS filesystems for swapfiles.
Check running kernel versions against vendor fixed-build guidance.
Review boot, dm-verity, and F2FS logs for corruption symptoms.
Confirm patched kernels include one referenced stable commit.
Regression-test swap stress and reboot behavior on representative devices.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2026-23233 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
0CVSS vectors
3Timeline events
0ADP providers
6Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
Mar 4, 2026, 14:36 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.