CVE-2026-93235
Received Received - Intake

File size extension data leak in F2FS

Publication date: 2026-09-24

Last updated on: 2026-09-24

Assigner: kernel.org

Description
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 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.

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published
2026-09-24
Last Modified
2026-09-24
Generated
2026-09-25
AI Q&A
2026-09-24
EPSS Evaluated
N/A
NVD
CVE-2026-93235
EUVD
EUVD-2026-86240

Affected Vendors & Products

Showing 1 associated CPE
Vendor Product Version / Range
linux_kernel f2fs *

Helpful Resources

Exploitability

CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN

Attack-Flow Graph

AI Quick Actions

Instant insights powered by AI
Executive Summary

This vulnerability in the Linux kernel's F2FS filesystem allows stale data to remain in the gap between the old and new file sizes when extending a file. Normally, this gap should be zeroed out to prevent exposure of old data after a system restart or crash.

Detection Guidance

This vulnerability affects the F2FS filesystem in the Linux kernel and may leave non-zero data in gaps after file operations. Detection requires running specific filesystem tests like generic/794 from fstests. Use commands: fiemap to check physical block allocation, truncate or fallocate to extend files, and verify data in gaps after remount or crash recovery.

Impact Analysis

If exploited, this flaw could lead to unintended data exposure where sensitive information from previously deleted files might be visible after file operations or system crashes. It primarily affects systems using F2FS with specific file extension methods like truncate, fallocate, or write operations.

Compliance Impact

This vulnerability could potentially violate data protection requirements under GDPR and HIPAA by allowing unauthorized access to residual data. Organizations must ensure proper data sanitization to maintain compliance, as stale data exposure may constitute a breach of confidentiality requirements.

Mitigation Strategies

Apply the Linux kernel patch fixing the F2FS post-EOF data zeroing issue. For systems where F2FS is used, mount the filesystem with the fsync_mode=strict option to enforce stricter writeback behavior. Ensure all file operations (truncate, fallocate, write) properly zero post-EOF data before committing changes.

Chat Assistant

Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-93235. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70

EPSS Chart