UBUNTU-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 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.
02 / AFFECTED SOFTWARE
Affected packages
11 explicit affected versions
50 explicit affected versions
6 explicit affected versions
12 explicit affected versions
19 explicit affected versions
10 explicit affected versions
6 explicit affected versions
24 explicit affected versions
10 explicit affected versions
36 explicit affected versions
26 explicit affected versions
7 explicit affected versions
39 explicit affected versions
13 explicit affected versions
43 explicit affected versions
35 explicit affected versions
18 explicit affected versions
44 explicit affected versions
13 explicit affected versions
4 explicit affected versions
23 explicit affected versions
51 explicit affected versions
1 explicit affected versions
21 explicit affected versions
7 explicit affected versions
16 explicit affected versions
10 explicit affected versions
20 explicit affected versions
47 explicit affected versions
8 explicit affected versions
7 explicit affected versions
12 explicit affected versions
11 explicit affected versions
7 explicit affected versions
12 explicit affected versions
14 explicit affected versions
10 explicit affected versions
1 explicit affected versions
7 explicit affected versions
16 explicit affected versions
12 explicit affected versions
10 explicit affected versions
12 explicit affected versions
40 explicit affected versions
16 explicit affected versions
17 explicit affected versions
27 explicit affected versions
33 explicit affected versions
10 explicit affected versions
37 explicit affected versions
10 explicit affected versions
11 explicit affected versions
13 explicit affected versions
38 explicit affected versions
3 explicit affected versions
10 explicit affected versions
11 explicit affected versions
26 explicit affected versions
9 explicit affected versions
13 explicit affected versions
29 explicit affected versions
13 explicit affected versions
12 explicit affected versions
40 explicit affected versions
39 explicit affected versions
8 explicit affected versions
33 explicit affected versions
23 explicit affected versions
10 explicit affected versions
19 explicit affected versions
18 explicit affected versions
11 explicit affected versions
5 explicit affected versions
12 explicit affected versions
11 explicit affected versions
7 explicit affected versions
12 explicit affected versions
10 explicit affected versions
16 explicit affected versions
5 explicit affected versions
10 explicit affected versions
26 explicit affected versions
39 explicit affected versions
35 explicit affected versions
46 explicit affected versions
11 explicit affected versions
10 explicit affected versions
13 explicit affected versions
45 explicit affected versions
16 explicit affected versions
49 explicit affected versions
3 explicit affected versions
7 explicit affected versions
15 explicit affected versions
51 explicit affected versions
16 explicit affected versions
18 explicit affected versions
41 explicit affected versions
12 explicit affected versions
7 explicit affected versions
27 explicit affected versions
42 explicit affected versions
8 explicit affected versions
5 explicit affected versions
8 explicit affected versions
10 explicit affected versions
7 explicit affected versions
45 explicit affected versions
13 explicit affected versions
13 explicit affected versions
7 explicit affected versions
8 explicit affected versions
10 explicit affected versions
12 explicit affected versions
9 explicit affected versions
44 explicit affected versions
16 explicit affected versions
3 explicit affected versions
13 explicit affected versions
26 explicit affected versions
45 explicit affected versions
37 explicit affected versions
49 explicit affected versions
14 explicit affected versions
38 explicit affected versions
9 explicit affected versions
17 explicit affected versions
11 explicit affected versions
38 explicit affected versions
17 explicit affected versions
14 explicit affected versions
6 explicit affected versions
7 explicit affected versions
4 explicit affected versions
10 explicit affected versions
1 explicit affected versions
13 explicit affected versions
43 explicit affected versions
16 explicit affected versions
10 explicit affected versions
8 explicit affected versions
44 explicit affected versions
14 explicit affected versions
4 explicit affected versions
78 explicit affected versions
14 explicit affected versions
11 explicit affected versions
1 explicit affected versions
18 explicit affected versions
38 explicit affected versions
03 / CONNECTIONS
Connected vulnerabilities
04 / EVIDENCE
Source records
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.
05 / REFERENCES
Further evidence
- https://git.kernel.org/linus/5c145c03188bc9ba1c29e0bc4d527a5978fc47f9
- https://git.kernel.org/stable/c/1ff415eef513bf12deb058fc50d57788c46c48e6
- https://git.kernel.org/stable/c/5c145c03188bc9ba1c29e0bc4d527a5978fc47f9
- https://git.kernel.org/stable/c/607cb9d83838d2cd9f0406c2403ed61aadf0edff
- https://git.kernel.org/stable/c/d4534a7f6c92baaf7e12a45fc6e37332cafafc33
- https://git.kernel.org/stable/c/fee27b69dde1a05908b350eea42937af2387c4fe
- https://ubuntu.com/security/CVE-2026-23233
- https://ubuntu.com/security/notices/USN-8492-1
- https://ubuntu.com/security/notices/USN-8492-2
- https://ubuntu.com/security/notices/USN-8492-3
- https://ubuntu.com/security/notices/USN-8492-4
- https://ubuntu.com/security/notices/USN-8492-5
- https://ubuntu.com/security/notices/USN-8497-1
- https://ubuntu.com/security/notices/USN-8498-1
- https://ubuntu.com/security/notices/USN-8499-1
- https://ubuntu.com/security/notices/USN-8606-1
- https://ubuntu.com/security/notices/USN-8607-1
- https://ubuntu.com/security/notices/USN-8609-1
- https://ubuntu.com/security/notices/USN-8619-1
- https://www.cve.org/CVERecord?id=CVE-2026-23233