f2fs: fix to zero post-EOF data when extending file size

Summary

CVECVE-2026-93235
StatePUBLISHED
AssignerLinux
Source PriorityCVE Program / NVD first with legacy fallback
Published2026-09-24 16:17:19 UTC
Updated2026-09-24 16:17:19 UTC
DescriptionIn 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 append_write +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 truncate_up ... (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 i_size. 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/ fsync_mode=strict mount option.

Vendor Declared Affected Products

SourceVendorProductVersionPlatforms
CNA Linux Linux affected 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 6882d458d2e403f6ba7b45542dd31a6b7531eb2e git Not specified
CNA Linux Linux affected 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 32c7f11a24268ba8d3bb50ea7f54d33f698cd253 git Not specified
CNA Linux Linux affected 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 91ec55ddc097ccddd25ffb95a3d079b2ef362372 git Not specified
CNA Linux Linux affected 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 c42608c09b6b5d5967bf211c255914c068c2cde1 git Not specified
CNA Linux Linux affected 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 5eced87b7d19dbc76ebdddaf322046f9ac582fcb git Not specified
CNA Linux Linux affected 6.6.157 semver Not specified
CNA Linux Linux affected 6.12.110 semver Not specified
CNA Linux Linux affected 6.18.51 semver Not specified
CNA Linux Linux affected 7.2.5 semver Not specified
CNA Linux Linux unaffected 6.6.157 6.6.* semver Not specified
CNA Linux Linux unaffected 6.12.110 6.12.* semver Not specified
CNA Linux Linux unaffected 6.18.51 6.18.* semver Not specified
CNA Linux Linux unaffected 7.2.5 7.2.* semver Not specified
CNA Linux Linux unaffected 7.3-rc1 * original_commit_for_fix Not specified

References

ReferenceSourceLinkTags
git.kernel.org/stable/c/6882d458d2e403f6ba7b45542dd31a6b7531eb2e 416baaa9-dc9f-4396-8d5f-8c081fb06d67 git.kernel.org
git.kernel.org/stable/c/c42608c09b6b5d5967bf211c255914c068c2cde1 416baaa9-dc9f-4396-8d5f-8c081fb06d67 git.kernel.org
git.kernel.org/stable/c/5eced87b7d19dbc76ebdddaf322046f9ac582fcb 416baaa9-dc9f-4396-8d5f-8c081fb06d67 git.kernel.org
git.kernel.org/stable/c/91ec55ddc097ccddd25ffb95a3d079b2ef362372 416baaa9-dc9f-4396-8d5f-8c081fb06d67 git.kernel.org
git.kernel.org/stable/c/32c7f11a24268ba8d3bb50ea7f54d33f698cd253 416baaa9-dc9f-4396-8d5f-8c081fb06d67 git.kernel.org
CVE Program record CVE.ORG www.cve.org canonical
NVD vulnerability detail NVD nvd.nist.gov canonical, analysis

© CVE.report 2026

Use of this information constitutes acceptance for use in an AS IS condition. There are NO warranties, implied or otherwise, with regard to this information or its use. Any use of this information is at the user's risk. It is the responsibility of user to evaluate the accuracy, completeness or usefulness of any information, opinion, advice or other content. EACH USER WILL BE SOLELY RESPONSIBLE FOR ANY consequences of his or her direct or indirect use of this web site. ALL WARRANTIES OF ANY KIND ARE EXPRESSLY DISCLAIMED. This site will NOT BE LIABLE FOR ANY DIRECT, INDIRECT or any other kind of loss.

CVE, CWE, and OVAL are registred trademarks of The MITRE Corporation and the authoritative source of CVE content is MITRE's CVE web site. This site includes MITRE data granted under the following license.

Free CVE JSON API cve.report/api

CVE.report and Source URL Uptime Status status.cve.report