LiveActive security incident?Get immediate response
CVE Record

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.

UnknownCVSS not scoredNot KEV-listedUpdated
Glexia's TakeAutomated analysismoderate

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.
Prepared
Confidence
medium
Sources
7

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.

Open ATT&CK lookup
Vulnerability profileCVE Program record
Severity
Unknown
CVSS
Not scored
Known Exploited
No
Published
Official CVE source material

CNA and ADP enrichment extracted from CVE v5

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.

  1. CVE reservedCVE Program

    The CVE ID was reserved by the assigning CNA.

  2. CVE publishedCVE Program

    The CVE record was published.

  3. CVE updatedCVE Program

    The CVE record metadata indicates this as the latest update time.

Affected products

Products and packages named in the record

VendorProductVersion / packageStatus
LinuxLinux40d76c393cca83938b11eb7ca8983aa3cd0ed69b, 9703d69d9d153bb230711d0d577454552aeb13d4, 9703d69d9d153bb230711d0d577454552aeb13d4, 9703d69d9d153bb230711d0d577454552aeb13d4, 9703d69d9d153bb230711d0d577454552aeb13d4, 6.6.33unaffected
LinuxLinux6.9, 0, 6.6.127, 6.12.74, 6.18.13, 6.19.3, 7.0affected
Weakness

CWE details

No CWE listed

CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.