CVE-2025-68769: f2fs: fix return value of f2fs_recover_fsync_data()
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix return value of f2fs_recover_fsync_data()
With below scripts, it will trigger panic in f2fs:
mkfs.f2fs -f /dev/vdd
mount /dev/vdd /mnt/f2fs
touch /mnt/f2fs/foo
sync
echo 111 >> /mnt/f2fs/foo
f2fs_io fsync /mnt/f2fs/foo
f2fs_io shutdown 2 /mnt/f2fs
umount /mnt/f2fs
mount -o ro,norecovery /dev/vdd /mnt/f2fs
or
mount -o ro,disable_roll_forward /dev/vdd /mnt/f2fs
F2FS-fs (vdd): f2fs_recover_fsync_data: recovery fsync data, check_only: 0
F2FS-fs (vdd): Mounted with checkpoint version = 7f5c361f
F2FS-fs (vdd): Stopped filesystem due to reason: 0
F2FS-fs (vdd): f2fs_recover_fsync_data: recovery fsync data, check_only: 1
Filesystem f2fs get_tree() didn't set fc->root, returned 1
------------[ cut here ]------------
kernel BUG at fs/super.c:1761!
Oops: invalid opcode: 0000 [#1] SMP PTI
CPU: 3 UID: 0 PID: 722 Comm: mount Not tainted 6.18.0-rc2+ #721 PREEMPT(voluntary)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
RIP: 0010:vfs_get_tree.cold+0x18/0x1a
Call Trace:
<TASK>
fc_mount+0x13/0xa0
path_mount+0x34e/0xc50
__x64_sys_mount+0x121/0x150
do_syscall_64+0x84/0x800
entry_SYSCALL_64_after_hwframe+0x76/0x7e
RIP: 0033:0x7fa6cc126cfe
The root cause is we missed to handle error number returned from
f2fs_recover_fsync_data() when mounting image w/ ro,norecovery or
ro,disable_roll_forward mount option, result in returning a positive
error number to vfs_get_tree(), fix it.
Security readout for executives and security teams
Plain-English summary
This Linux kernel issue can crash a system when F2FS recovery handling returns the wrong value during a read-only mount using recovery-disabling options. The business impact is availability, not confirmed data theft or remote compromise. Treat it seriously on systems that mount F2FS media or images, especially from untrusted sources.
Executive priority
Prioritize patching where F2FS is used in production, embedded devices, removable media workflows, or image-processing environments. For general servers that never mount F2FS, urgency is lower but should still follow normal kernel update cycles.
Technical view
The bug is in f2fs_recover_fsync_data(). During F2FS mount paths using ro,norecovery or ro,disable_roll_forward, an error return was not handled correctly and a positive value reached vfs_get_tree(), causing a kernel BUG and panic. The fix corrects the return value handling.
Likely exposure
Exposure is limited to Linux systems using F2FS or able to mount F2FS filesystem images. Highest concern is hosts, appliances, test systems, or recovery workflows where users or automation mount F2FS media, disk images, or block devices.
Exploitation context
The source shows a reproducible kernel panic scenario but does not show active exploitation. KEV is false, and no public exploit status is provided. The apparent impact is denial of service through a kernel crash after mounting a prepared F2FS state.
Researcher notes
Evidence is strongest for a local denial-of-service condition in the F2FS mount path. The bundle provides no CVSS, CWE, distribution package mapping, or proof of remote reachability. Avoid assuming broader privilege escalation or confidentiality impact without additional vendor analysis.
Mitigation direction
Update affected Linux kernels to versions containing the referenced stable fixes.
Check Linux distribution advisories for package-specific fixed kernel versions.
Avoid mounting untrusted F2FS media or images on vulnerable systems.
Restrict who can mount block devices or filesystem images.
Use operational controls for removable media and recovery environments.
Validation and detection
Inventory systems with F2FS support enabled or F2FS filesystems in use.
Compare running kernel versions against vendor advisories and stable fix commits.
Review mount workflows for ro,norecovery or ro,disable_roll_forward usage.
Check logs for F2FS mount failures followed by kernel panic events.
Confirm patched kernels include the referenced f2fs return-value fix.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2025-68769 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
0CVSS vectors
3Timeline events
0ADP providers
8Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
Jan 13, 2026, 15:28 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.