CVE-2026-93235: f2fs: fix to zero post-EOF data when extending file size
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to zero post-EOF data when extending file size
generic/794 4s ... - output mismatch (see /share/git/fstests/results//generic/794.out.bad) --- tests/generic/794.out 2026-06-12 08:46:32.766426241 +0800 +++ /share/git/fstests/results//generic/794.out.bad 2026-07-05 18:32:55.000000000 +0800 @@ -1,4 +1,16 @@ QA output created by 794 appendwrite +FAIL: non-zero data in gap [4080,4096) after shutdown+remount +000000 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a >ZZZZZZZZZZZZZZZZ< + +001000 truncateup ... (Run 'diff -u /share/git/fstests/tests/generic/794.out /share/git/fstests/results//generic/794.out.bad' to see the entire diff) Ran: generic/794 Failures: generic/794 Failed 1 of 1 tests
Steps of generic/794: 1. write 4096 bytes to file w/ 0x5a 2. use fiemap to get PBA of first block in file 3. truncate file to 4080 4. umount; write 4096 bytes to file w/ 0x5a directly via PBA; mount 5. extend filesize via a) append 4096 from offset 4096, or b) truncate 8192, or c) fallocate 4096 from offset 4096 6. verify the gap is zeroed in memory [4080,4096) 7. sync range 4096 from offset 4096; shutdown -f (flush meta before shutdown) 8. umount; mount; verify [4080,4096) is zeroed or not.
When extending file size (e.g. via truncate, fallocate, or write) across an unaligned EOF boundary, we need to ensure that post-EOF data in the partial page is zeroed out in pagecache and marked dirty, then writeback the cache to persist zeroed data before committing inode w/ updated isize.
This help to prevent stale disk data beyond the previous EOF from being exposed after remounting or crash recovery.
Since f2fs is a LFS filesystem, we only support direct write via PBA in pinfile, and pinfile has section-aligned filesize, so in Android, there should no problem, but for other usage in different environment, let's fix this w/ fsyncmode=strict mount option.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Mount the f2fs filesystem with the fsync_mode=strict option to ensure post-EOF data is zeroed when extending file size.
f2fs filesystem fsync_mode = strict
Event History
Frequently Asked Questions
What access or conditions are required to reproduce the issue?
The reproduced failure requires an f2fs filesystem containing a file whose size is reduced from 4096 bytes to 4080 bytes, followed by an unmount and a direct write of 0x5a bytes to the file’s first physical block address. After remounting, extending the file through append, truncate, or fallocate exposes the affected gap.
How can I check whether a system is affected?
Run the xfstests generic/794 test against the f2fs filesystem. An affected system reports non-zero data in the [4080,4096) gap after shutdown and remount, with 0x5a bytes shown instead of zeroes.
Which file-growth operations were observed to trigger the stale-data condition?
The failure was reproduced when extending the file by appending 4096 bytes at offset 4096, truncating the file to 8192 bytes, or using fallocate for 4096 bytes at offset 4096. In each case, the pre-existing partial-block gap should be zeroed.