In the Linux kernel, the following vulnerability has been resolved:
f2fs: limit recovery filename logging to stored length
F2FS stores recovery filenames as a length plus a fixed-size i_name
buffer. The buffer is not NUL-terminated, but recover_inode() and
recover_dentry() print it with %s.
For a 255-byte filename, recovery logging can read past i_name into the
following raw inode fields.
Print the name with a precision bounded by i_namelen and F2FS_NAME_LEN.
CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
CVSS Score: 7.1
AV:L - recover_inode() and recover_dentry() run only during local f2fs roll-forward in f2fs_fill_super() -> f2fs_recover_fsync_data(). This is a local block filesystem (Android userdata/portable storage), not a network protocol path such as ksmbd or nfsd.
AC:L - A crafted f2fs image with a 255-byte non-NUL i_name and a pending fsync node makes printk %s over-read deterministically on mount. Roll-forward is default-enabled; no race or attacker-uncontrollable layout is required.
PR:L - f2fs lacks FS_USERNS_MOUNT, but Android vold auto-mounts f2fs portable/adoptable storage and desktop/kiosk udisks2/polkit mounts removable media for an ordinary console user, so init-namespace root is not required.
UI:N - The attacker supplies the crafted image; vold/udisks auto-mount runs roll-forward recovery without a separate deliberate victim mount or open. Recovery also fires automatically on the next mount after an unclean shutdown.
S:U - The over-read and any resulting oops stay in the host kernel address space and security authority. This is not a VM escape, IOMMU bypass, or sandbox boundary crossing.
C:H - recover_inode()/recover_dentry() pass the 255-byte, non-NUL-terminated i_name to printk %s with no precision, so vsprintf scans past the field and the rest of the 4KB node folio into adjacent kernel memory and copies it into dmesg, an unbounded OOB read.
I:N - The defect is a read-only printk over-read of i_name; it does not write kernel memory, corrupt adjacent objects, or provide a control-flow hijack primitive.
A:H - Unbounded %s scanning off the node folio can walk into unmapped pages or trip KASAN/page-poisoning and oops/panic the kernel during mount recovery, fully denying availability.
| Attack Vector |
Local |
Scope |
Unchanged |
| Attack Complexity |
Low |
Confidentiality Impact |
High |
| Privileges Required |
Low |
Integrity Impact |
None |
| User Interaction |
None |
Availability Impact |
High |
AV:L - recover_inode() and recover_dentry() run only during local f2fs roll-forward in f2fs_fill_super() -> f2fs_recover_fsync_data(). This is a local block filesystem (Android userdata/portable storage), not a network protocol path such as ksmbd or nfsd.
AC:L - A crafted f2fs image with a 255-byte non-NUL i_name and a pending fsync node makes printk %s over-read deterministically on mount. Roll-forward is default-enabled; no race or attacker-uncontrollable layout is required.
PR:L - f2fs lacks FS_USERNS_MOUNT, but Android vold auto-mounts f2fs portable/adoptable storage and desktop/kiosk udisks2/polkit mounts removable media for an ordinary console user, so init-namespace root is not required.
UI:N - The attacker supplies the crafted image; vold/udisks auto-mount runs roll-forward recovery without a separate deliberate victim mount or open. Recovery also fires automatically on the next mount after an unclean shutdown.
S:U - The over-read and any resulting oops stay in the host kernel address space and security authority. This is not a VM escape, IOMMU bypass, or sandbox boundary crossing.
C:H - recover_inode()/recover_dentry() pass the 255-byte, non-NUL-terminated i_name to printk %s with no precision, so vsprintf scans past the field and the rest of the 4KB node folio into adjacent kernel memory and copies it into dmesg, an unbounded OOB read.
I:N - The defect is a read-only printk over-read of i_name; it does not write kernel memory, corrupt adjacent objects, or provide a control-flow hijack primitive.
A:H - Unbounded %s scanning off the node folio can walk into unmapped pages or trip KASAN/page-poisoning and oops/panic the kernel during mount recovery, fully denying availability.
CVSS 3.1