CVE-2026-63817

What it actually does

This is an improper input validation flaw in the Linux kernel F2FS filesystem code. When the F2FS compressed page cache feature is not enabled, a corrupted directory entry can reference a synthetic inode number equal to max_nid that should be considered outside the valid inode range. Because the kernel incorrectly treated that synthetic compressed-cache inode as a metadata inode even when compress_cache was disabled, f2fs_iget() could bypass the normal inode range validation path and instantiate an internal fake inode. With local privileges and the ability to introduce or mount a crafted/corrupted F2FS filesystem image or otherwise influence F2FS directory metadata, an attacker may be able to trigger kernel memory corruption, kernel crashes, or potentially elevate privileges, consistent with the CVSS impact of high confidentiality, integrity, and availability loss.

Why it matters to the business

Systems that mount untrusted or attacker-controlled F2FS filesystems are at risk of local compromise or service disruption. The most likely operational impact is a kernel crash or host instability, but because this issue occurs in kernel filesystem parsing logic, successful exploitation could also lead to full host takeover. Risk is highest for endpoints, mobile/embedded Linux devices, removable-media workflows, sandbox/container hosts that allow filesystem mounting, and services that automatically inspect or mount disk images. The EPSS score is currently low and the issue is not listed in CISA KEV, so there is no public signal of widespread exploitation, but the kernel-level impact warrants timely patching where F2FS is enabled or supported.

How an attack unfolds

An attacker first needs local access or a path to supply a crafted F2FS filesystem or corrupted F2FS metadata to a vulnerable Linux system. The attacker creates or modifies a directory entry so that it references an inode number equal to the filesystem's max_nid value while the compress_cache mount option is disabled. When the vulnerable kernel processes that directory entry, the F2FS inode lookup logic incorrectly classifies the out-of-range synthetic compressed-cache inode as a valid metadata inode. This bypasses the expected range validation in the normal inode read path and causes the kernel to instantiate an internal inode object that should not exist in that configuration. Depending on kernel build, filesystem state, and memory layout, this can result in denial of service through a kernel fault or may provide primitives useful for local privilege escalation. No known public exploit maturity or named threat actor activity is reported in the supplied intelligence.

How to fix it

Apply a Linux kernel update that includes the F2FS fix which validates the compressed-cache synthetic inode only when the COMPRESS_CACHE option is enabled. If vendor fixed package versions are available for the relevant distribution or appliance, upgrade to those versions or later. Where immediate patching is not possible, reduce exposure by disabling F2FS support if it is not required, preventing unprivileged users from mounting filesystems, blocking automatic mounting of removable media or disk images, and avoiding processing untrusted F2FS images. Use mount, udev, desktop automount, container runtime, and sandbox policies to ensure untrusted users cannot cause vulnerable kernels to mount attacker-supplied F2FS volumes.

How to confirm the fix worked

Confirm the running kernel contains the vendor patch for the F2FS compressed-cache inode validation change. Validate by checking the distribution kernel changelog, package advisory, or source commit history for the fix that gates F2FS_COMPRESS_INO handling on COMPRESS_CACHE. Confirm whether F2FS is available or loaded by checking kernel configuration and loaded modules, and review whether F2FS filesystems are mounted. After patching, reboot into the fixed kernel and verify with uname/package manager output that the active kernel is the updated version, not only installed on disk. If feasible in a controlled test environment, attempt to mount or inspect a crafted F2FS image that previously triggered the condition and confirm it is rejected as an out-of-range inode rather than causing kernel instability.

Typical attack path

1. Gain local execution or obtain an equivalent path to cause the target system to mount or process attacker-controlled F2FS filesystem metadata.
2. Prepare a malicious or corrupted F2FS filesystem image containing a directory entry that points to ino == max_nid.
3. Ensure the filesystem is mounted or parsed with the compress_cache option disabled.
4. Trigger a lookup or access path that causes the kernel to process the crafted directory entry through f2fs_iget().
5. Exploit the resulting incorrect internal inode instantiation to crash the kernel or attempt privilege escalation.

How to detect it

Retrospective detection should focus on evidence that untrusted or unusual F2FS filesystems were mounted or processed, followed by kernel errors, oopses, panics, or unexpected privilege changes. Review system journal logs, kernel ring buffer logs, audit logs, mount history, removable-media events, endpoint telemetry, and crash dumps. Look for F2FS mount events, failed F2FS inode lookups, out-of-range inode messages, kernel warnings in F2FS functions, and crashes temporally associated with mounting removable media, loop devices, or disk images. On systems with auditd, review mount syscall activity and loop-device setup by non-administrative users. On container or sandbox hosts, review whether workloads were permitted to create loop devices, mount F2FS images, or use elevated capabilities such as CAP_SYS_ADMIN. Because no public exploit artifacts or threat actors are identified in the supplied intelligence, absence of fixed strings does not prove absence of exploitation; prioritize behavioral correlation between F2FS activity and kernel instability.

• F2FS-fs
• f2fs_iget
• f2fs_check_nid_range
• out-of-range nid
• invalid nid
• compress_cache
• loop device
• mount -t f2fs

What your security team should do

• Prioritize patching Linux systems that use F2FS, support removable media, run mobile or embedded Linux workloads, process disk images, or allow users/containers to mount filesystems.
• Inventory systems where the F2FS kernel module is present, loaded, or where F2FS filesystems are mounted.
• Restrict filesystem mounting to trusted administrators; ensure unprivileged user namespaces and unprivileged mounts are disabled where not required.
• Disable or blacklist the F2FS module on systems that do not need F2FS support.
• Disable automount of removable media and prevent automated inspection of untrusted F2FS images until patched.
• Monitor for kernel oops, panic, or F2FS error messages around the time removable media or disk images are mounted.
• Treat unexplained kernel crashes on systems handling untrusted storage as potential security events and preserve crash dumps and relevant logs.
• Track vendor advisories for exact fixed kernel versions because the supplied data does not include per-product fixed versions.