CVE-2026-93235

CVE CVE-2026-93235EUVD EUVD-2026-86240Published 2026-09-24T15:33:33.000ZLast changed 2026-09-25T12:42:38.000Z

What the advisory describes

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.

Source: EUVD (ENISA), in the words of the advisory.

Products the advisory names

These come from the advisory itself, not from any check we performed.

• Linux — Linux patch: 0; 3.8; patch: 6.18.51; patch: 6.6.157; patch: 7.3-rc1; fbfa2cc58d5363f780f4f2ad0243a47185c2bb2a <6882d458d2e403f6ba7b45542dd31a6b7531eb2e; fbfa2cc58d5363f780f4f2ad0243a47185c2bb2a <32c7f11a24268ba8d3bb50ea7f54d33f698cd253; patch: 6.12.110; fbfa2cc58d5363f780f4f2ad0243a47185c2bb2a <91ec55ddc097ccddd25ffb95a3d079b2ef362372; patch: 7.2.5; fbfa2cc58d5363f780f4f2ad0243a47185c2bb2a <c42608c09b6b5d5967bf211c255914c068c2cde1; fbfa2cc58d5363f780f4f2ad0243a47185c2bb2a <5eced87b7d19dbc76ebdddaf322046f9ac582fcb

The versions shown are the advisory's own. Patchlage compares no version numbers and derives no judgement from them — which version is installed is something a person has to look up.

Carried in the product catalogue

An estate covering these products can be recorded in Patchlage. An advisory about them appears in the next morning's situation report.

• Linux — Linux

Patchlage reports hits and suspected hits. About everything else this system says nothing — neither this page nor the situation report ever claims that an estate is safe.