cbcvebase.
CVE-2026-23233
published 2026-03-04

CVE-2026-23233: 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…

PriorityP341high7.8CVSS 3.1
AVLACLPRLUINSUCHIHAH
EPSS
0.16%
5.6th percentile
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 (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.

Affected

46 ranges· showing 25
VendorProductVersion rangeFixed in
debianlinux< linux 6.18.13-1 (forky)linux 6.18.13-1 (forky)
linuxlinux
linuxlinux>= 40d76c393cca83938b11eb7ca8983aa3cd0ed69b < d4534a7f6c92baaf7e12a45fc6e37332cafafc33d4534a7f6c92baaf7e12a45fc6e37332cafafc33
linuxlinux>= 6.6.33 < 6.6.1276.6.127
linuxlinux>= 9703d69d9d153bb230711d0d577454552aeb13d4 < 1ff415eef513bf12deb058fc50d57788c46c48e61ff415eef513bf12deb058fc50d57788c46c48e6
linuxlinux>= 9703d69d9d153bb230711d0d577454552aeb13d4 < fee27b69dde1a05908b350eea42937af2387c4fefee27b69dde1a05908b350eea42937af2387c4fe
linuxlinux>= 9703d69d9d153bb230711d0d577454552aeb13d4 < 607cb9d83838d2cd9f0406c2403ed61aadf0edff607cb9d83838d2cd9f0406c2403ed61aadf0edff
linuxlinux>= 9703d69d9d153bb230711d0d577454552aeb13d4 < 5c145c03188bc9ba1c29e0bc4d527a5978fc47f95c145c03188bc9ba1c29e0bc4d527a5978fc47f9
linuxlinux_kernel>= 0 < 6.12.74-26.12.74-2
linuxlinux_kernel>= 0 < 6.18.13-16.18.13-1
linuxlinux_kernel>= 6.13 < 6.18.136.18.13
linuxlinux_kernel>= 6.19 < 6.19.36.19.3
linuxlinux_kernel>= 6.6.33 < 6.6.1276.6.127
linuxlinux_kernel>= 6.9 < 6.12.746.12.74
msrcazl3_kernel_6.6.126.1-1_on_azure_linux_3.0
ubuntulinux
ubuntulinux-aws
ubuntulinux-aws-6.8
ubuntulinux-aws-fips
ubuntulinux-azure
ubuntulinux-azure-6.8
ubuntulinux-azure-fde
ubuntulinux-azure-fde-6.8
ubuntulinux-azure-fips
ubuntulinux-fips

CVSS provenance

nvdv3.17.8HIGHCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
osv7.8HIGH
vendor_ubuntu8.8HIGH
vendor_debian7.8LOW
vendor_msrc7.8HIGH
vendor_redhat7.8HIGH
Stop checking back — get the weekly exploitation signal.

Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.