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: 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.
- Products
- Kernel
- Affected versions
- Not specified
- Fixed versions
- 5.10.248, 5.15.198, 6.1.160, 6.12.64, 6.18.3, 6.6.120
- CVEs
- CVE-2025-68769
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 28 Oct 2026, 08:57 UTC · Revision 1
Source evidence
f2fs: fix return value of f2fs_recover_fsync_data()
core-osv · Original sourcePublished 13 Jan 2026, 15:28 UTC
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: 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.
osv:CVE-2025-68769
Kernel
Fixed versions: 5.10.248, 5.15.198, 6.1.160, 6.6.120, 6.12.64, 6.18.3
Complete source record
{
"id": "d797db5d6e9b2107b23561d32fed9dd7e67930390bb3d24e266fe0c112679768",
"url": "https://osv.dev/vulnerability/CVE-2025-68769",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "f2fs: fix return value of f2fs_recover_fsync_data()",
"summary": "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: 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.",
"evidence": "osv:CVE-2025-68769",
"products": [
{
"name": {
"value": "Kernel",
"evidence": "/affected/1/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "5.10.248",
"evidence": "/affected/1/ranges"
},
{
"value": "5.15.198",
"evidence": "/affected/1/ranges"
},
{
"value": "6.1.160",
"evidence": "/affected/1/ranges"
},
{
"value": "6.6.120",
"evidence": "/affected/1/ranges"
},
{
"value": "6.12.64",
"evidence": "/affected/1/ranges"
},
{
"value": "6.18.3",
"evidence": "/affected/1/ranges"
}
],
"affected_versions": []
}
],
"severity": "unknown",
"structured": {
"id": "CVE-2025-68769",
"aliases": [
"CVE-2025-68769"
],
"affected": [
{
"ranges": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "6781eabba1bdb133eb9125c4acf6704ccbe4df02"
},
{
"fixed": "e6ac31abd30e9fd2ef5f0819ce7f3f932be3b725"
},
{
"fixed": "0de4977a1eeafe9d77701e3c031a1bcdba389243"
},
{
"fixed": "9bc246018aaa3b46a7710428d0a2196c229f9d49"
},
{
"fixed": "a4c67d96f92eefcfa5596a08f069e77b743c5865"
},
{
"fixed": "473550e715654ad7612aa490d583cb7c25fe2ff3"
},
{
"fixed": "4560db9678a2c5952b6205fbca468c6805c2ba2a"
},
{
"fixed": "01fba45deaddcce0d0b01c411435d1acf6feab7b"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "4.4.172"
},
{
"fixed": "4.5"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "1499d39b74f5957e932639a86487ccea5a0a9740"
}
]
}
],
"versions": [
"v4.4.302",
"v4.4.301",
"v4.4.300",
"v4.4.299",
"v4.4.298",
"v4.4.297",
"v4.4.296",
"v4.4.295",
"v4.4.294",
"v4.4.293",
"v4.4.292",
"v4.4.291",
"v4.4.290",
"v4.4.289",
"v4.4.288",
"v4.4.287",
"v4.4.286",
"v4.4.285",
"v4.4.284",
"v4.4.283",
"v4.4.282",
"v4.4.281",
"v4.4.280",
"v4.4.279",
"v4.4.278",
"v4.4.277",
"v4.4.276",
"v4.4.275",
"v4.4.274",
"v4.4.273",
"v4.4.272",
"v4.4.271",
"v4.4.270",
"v4.4.269",
"v4.4.268",
"v4.4.267",
"v4.4.266",
"v4.4.265",
"v4.4.264",
"v4.4.263",
"v4.4.262",
"v4.4.261",
"v4.4.260",
"v4.4.259",
"v4.4.258",
"v4.4.257",
"v4.4.256",
"v4.4.255",
"v4.4.254",
"v4.4.253",
"v4.4.252",
"v4.4.251",
"v4.4.250",
"v4.4.249",
"v4.4.248",
"v4.4.247",
"v4.4.246",
"v4.4.245",
"v4.4.244",
"v4.4.243",
"v4.4.242",
"v4.4.241",
"v4.4.240",
"v4.4.239",
"v4.4.238",
"v4.4.237",
"v4.4.236",
"v4.4.235",
"v4.4.234",
"v4.4.233",
"v4.4.232",
"v4.4.231",
"v4.4.230",
"v4.4.229",
"v4.4.228",
"v4.4.227",
"v4.4.226",
"v4.4.225",
"v4.4.224",
"v4.4.223",
"v4.4.222",
"v4.4.221",
"v4.4.220",
"v4.4.219",
"v4.4.218",
"v4.4.217",
"v4.4.216",
"v4.4.215",
"v4.4.214",
"v4.4.213",
"v4.4.212",
"v4.4.211",
"v4.4.210",
"v4.4.209",
"v4.4.208",
"v4.4.207",
"v4.4.206",
"v4.4.205",
"v4.4.204",
"v4.4.203",
"v4.4.202",
"v4.4.201",
"v4.4.200",
"v4.4.199",
"v4.4.198",
"v4.4.197",
"v4.4.196",
"v4.4.195",
"v4.4.194",
"v4.4.193",
"v4.4.192",
"v4.4.191",
"v4.4.190",
"v4.4.189",
"v4.4.188",
"v4.4.187",
"v4.4.186",
"v4.4.185",
"v4.4.184",
"v4.4.183",
"v4.4.182",
"v4.4.181",
"v4.4.180",
"v4.4.179",
"v4.4.178",
"v4.4.177",
"v4.4.176",
"v4.4.175",
"v4.4.174",
"v4.4.173",
"v4.4.172"
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2025-68769.json"
}
},
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "4.7.0"
},
{
"fixed": "5.10.248"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "5.11.0"
},
{
"fixed": "5.15.198"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "5.16.0"
},
{
"fixed": "6.1.160"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.2.0"
},
{
"fixed": "6.6.120"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.7.0"
},
{
"fixed": "6.12.64"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.13.0"
},
{
"fixed": "6.18.3"
}
]
}
],
"package": {
"name": "Kernel",
"ecosystem": "Linux"
},
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2025-68769.json"
}
}
],
"modified": "2026-10-08T02:49:09.294674088Z",
"provider": "osv",
"references": [
"https://git.kernel.org/stable/c/01fba45deaddcce0d0b01c411435d1acf6feab7b",
"https://git.kernel.org/stable/c/0de4977a1eeafe9d77701e3c031a1bcdba389243",
"https://git.kernel.org/stable/c/4560db9678a2c5952b6205fbca468c6805c2ba2a",
"https://git.kernel.org/stable/c/473550e715654ad7612aa490d583cb7c25fe2ff3",
"https://git.kernel.org/stable/c/9bc246018aaa3b46a7710428d0a2196c229f9d49",
"https://git.kernel.org/stable/c/a4c67d96f92eefcfa5596a08f069e77b743c5865",
"https://git.kernel.org/stable/c/e6ac31abd30e9fd2ef5f0819ce7f3f932be3b725",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2025/68xxx/CVE-2025-68769.json",
"https://nvd.nist.gov/vuln/detail/CVE-2025-68769",
"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
],
"provider_metadata": {
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2025/68xxx/CVE-2025-68769.json"
}
},
"related_cves": [
{
"value": "CVE-2025-68769",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": null
},
"source_id": "core-osv",
"document_id": 98296,
"published_at": "2026-01-13T15:28:47.798+00:00"
}