CVE-2026-63818

What it actually does

This flaw is in the Linux kernel F2FS filesystem recovery path. During mount-time orphan inode recovery, the kernel trusts an on-disk orphan block entry_count value from the checkpoint pack. If a crafted or corrupted F2FS image sets entry_count larger than F2FS_ORPHANS_PER_BLOCK, the recovery loop reads past the intended ino[] array and treats footer or adjacent checkpoint data as inode numbers. On vulnerable kernels, this can trigger f2fs_bug_on() and panic the kernel during mount. The practical impact is primarily local denial of service through a crafted filesystem image, though the out-of-bounds read occurs in kernel context and affects filesystem recovery integrity.

Why it matters to the business

A system that mounts an attacker-supplied or corrupted F2FS filesystem can crash, causing service interruption, node reboot, workload disruption, or loss of availability for devices and servers that rely on that kernel. The risk is highest for environments that automatically mount removable media, VM or container disk images, mobile/embedded storage, or user-provided filesystem images. This issue is not currently listed in CISA KEV, has no known ransomware association, and has low EPSS at publication time, but kernel panics can still create meaningful operational impact where local mounting of untrusted media is possible.

How an attack unfolds

An attacker creates a malicious F2FS filesystem image with a corrupted checkpoint orphan block whose entry_count exceeds the valid number of orphan inode entries. The attacker then gets a vulnerable Linux system to mount that image, for example through removable storage, a loop-mounted disk image, an imported VM image, an embedded device storage image, or an automount path. During mount, the F2FS driver replays orphan inodes from the checkpoint pack and iterates beyond the ino[] array because the entry count was not validated. The kernel interprets unrelated checkpoint footer or following data as inode numbers, reaches an invalid recovery condition, triggers f2fs_bug_on(), and panics. Successful exploitation does not require network access and is most realistic where an attacker can supply storage media or influence a local mount operation.

How to fix it

Update the Linux kernel to a version that includes the F2FS fix validating orphan inode entry_count before consuming orphan inode entries. Because no product-specific fixed versions were provided, use the fixed kernel package supplied by the relevant Linux distribution, device vendor, or kernel stable branch once available. Where immediate patching is not possible, reduce exposure by preventing untrusted users from mounting F2FS filesystems, disabling automatic mounting of removable or user-supplied media, restricting loop device creation and mount privileges, blocking F2FS mounts where not operationally required, and scanning/quarantining untrusted disk images before use. Systems that do not mount F2FS filesystems have substantially reduced practical exposure.

How to confirm the fix worked

Confirm the running kernel includes the F2FS orphan entry_count validation patch, not just that an updated package is installed but that the host has rebooted into the fixed kernel. Review distribution changelogs or kernel commit metadata for wording such as validating orphan inode entry count in f2fs_recover_orphan_inodes(). Validate configuration by confirming untrusted users cannot mount F2FS images or create loop-mounted filesystems unless required. In controlled testing only, a corrupted F2FS image that previously caused a panic should now fail the mount cleanly with filesystem corruption handling, such as an -EFSCORRUPTED-style failure and fsck request, rather than crashing the kernel. Check dmesg or journal logs after testing to ensure the system remains stable and records the corruption condition instead of a kernel BUG or panic.

Typical attack path

1. Prepare a crafted F2FS filesystem image with an invalid orphan block entry_count larger than F2FS_ORPHANS_PER_BLOCK.
2. Deliver the image to a vulnerable system through removable media, a disk image, VM image, container/embedded storage artifact, or another local file path.
3. Cause or wait for the vulnerable system to mount the crafted image using the F2FS kernel driver, directly or via automount/udisks-style handling.
4. During mount-time recovery, the kernel processes the corrupted checkpoint orphan data and reads past the expected orphan inode array.
5. The invalid recovery state triggers an F2FS kernel BUG condition and causes a kernel panic, interrupting the system.

How to detect it

Look for evidence that a vulnerable system mounted or attempted to mount an untrusted F2FS filesystem shortly before a kernel panic, reboot, or service outage. Useful sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, auditd logs, EDR process telemetry, shell history, removable media/udev logs, udisks logs, hypervisor image import logs, and crash dump metadata. Search for F2FS errors involving orphan inode recovery, checkpoint corruption, f2fs_recover_orphan_inodes(), f2fs_bug_on(), kernel BUG, Call Trace, panic, or unexpected reboots. Correlate those events with mount, losetup, udisksd, systemd-mount, guest image import, or removable device insertion events. If a crash dump is available, inspect the kernel stack for F2FS orphan recovery functions. Preserve any recently mounted F2FS disk image, loopback file, removable device, or VM storage artifact for offline analysis with fsck.f2fs and forensic tooling.

• f2fs_recover_orphan_inodes
• f2fs_bug_on
• F2FS-fs
• orphan inode
• orphan inodes
• checkpoint pack
• ERROR_INCONSISTENT_ORPHAN
• SBI_NEED_FSCK
• EFSCORRUPTED
• kernel BUG
• Kernel panic
• Call Trace:
• mount -t f2fs
• fsck.f2fs
• losetup
• /dev/loop
• udisksd
• systemd-mount

What your security team should do

• Prioritize kernel updates on systems that mount F2FS filesystems, handle removable media, process disk images, or run embedded/mobile storage workflows.
• Disable or restrict automatic mounting of removable media and user-supplied filesystem images, especially F2FS, until patched.
• Limit mount, loop device, and filesystem image handling privileges to trusted administrators or tightly confined services.
• Inventory systems with F2FS support or active F2FS mounts using mount output, /proc/filesystems, lsblk, and configuration management data.
• Monitor kernel logs for F2FS mount failures, orphan inode recovery errors, kernel BUG messages, and panic events involving f2fs_recover_orphan_inodes.
• If unexplained crashes occurred after mounting removable media or disk images, preserve kernel logs, the suspect image/media, and crash dumps for forensic review.
• For appliances or embedded devices, obtain vendor firmware or kernel updates that incorporate the upstream F2FS fix.