In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to clear dirty flag on folio in error path
If node block is corrupted due to chksum mismatch or inconsistent
footer info, it needs to drop clear flag of node folio, in order
to persist inconsistent node data to storage.
CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS Score: 7.8
AV:L - __get_node_folio is reached only through local VFS operations (lookup, open, read/write, fallocate, fsync, GC) on a mounted f2fs volume such as Android userdata or removable flash; it is not a ksmbd/nfsd/packet-processing path.
AC:L - A crafted f2fs image lets the attacker pick node footers and nids so a dirty direct-node folio is later re-fetched as NODE_TYPE_INODE (or fails checksum) on ordinary file ops; triggering is deterministic with no race or rare config.
PR:L - After automount (Android vold/udisks2 portable f2fs) or on already-mounted userdata, any unprivileged user with file access reaches __get_node_folio via write then lookup; no CAP_SYS_ADMIN is needed on that syscall path.
UI:N - The attacker dirties the node and then looks up the type-confused nid themselves; removable f2fs is commonly auto-mounted and scanned without a separate victim mount or open step.
S:U - Dirty-flag mishandling, persisted node metadata, and any page-cache fallout remain in the host kernel's authority; this is not a VM escape, container breakout, or IOMMU bypass.
C:H - A still-dirty corrupted node folio can be written back with inconsistent mappings, and a later read_node_folio will read into that dirty folio; file offsets can then resolve to other files' or leftover blocks and disclose their contents.
I:H - Writeback of the leftover dirty node persists inconsistent footer/checksum metadata, and the subsequent read into a dirty folio overwrites in-memory node contents from disk, corrupting block maps in an attacker-influenced way.
A:H - Footer failure on a still-dirty node stops checkpoint (and panics with errors=panic), can leak F2FS_DIRTY_NODES so checkpoint retries hang, and dirty !uptodate node folios can oops or freeze filesystem I/O.
| Attack Vector |
Local |
Scope |
Unchanged |
| Attack Complexity |
Low |
Confidentiality Impact |
High |
| Privileges Required |
Low |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
High |
AV:L - __get_node_folio is reached only through local VFS operations (lookup, open, read/write, fallocate, fsync, GC) on a mounted f2fs volume such as Android userdata or removable flash; it is not a ksmbd/nfsd/packet-processing path.
AC:L - A crafted f2fs image lets the attacker pick node footers and nids so a dirty direct-node folio is later re-fetched as NODE_TYPE_INODE (or fails checksum) on ordinary file ops; triggering is deterministic with no race or rare config.
PR:L - After automount (Android vold/udisks2 portable f2fs) or on already-mounted userdata, any unprivileged user with file access reaches __get_node_folio via write then lookup; no CAP_SYS_ADMIN is needed on that syscall path.
UI:N - The attacker dirties the node and then looks up the type-confused nid themselves; removable f2fs is commonly auto-mounted and scanned without a separate victim mount or open step.
S:U - Dirty-flag mishandling, persisted node metadata, and any page-cache fallout remain in the host kernel's authority; this is not a VM escape, container breakout, or IOMMU bypass.
C:H - A still-dirty corrupted node folio can be written back with inconsistent mappings, and a later read_node_folio will read into that dirty folio; file offsets can then resolve to other files' or leftover blocks and disclose their contents.
I:H - Writeback of the leftover dirty node persists inconsistent footer/checksum metadata, and the subsequent read into a dirty folio overwrites in-memory node contents from disk, corrupting block maps in an attacker-influenced way.
A:H - Footer failure on a still-dirty node stops checkpoint (and panics with errors=panic), can leak F2FS_DIRTY_NODES so checkpoint retries hang, and dirty !uptodate node folios can oops or freeze filesystem I/O.
CVSS 3.1