CVE-2026-63815

What it actually does

This is a Linux kernel F2FS filesystem parsing flaw caused by insufficient validation of the on-disk i_inline_xattr_size field when the flexible_inline_xattr feature is enabled. A crafted F2FS image can set an invalid inline extended-attribute size on an inode that does not actually use inline xattrs, causing inline directory and file geometry calculations to underflow. When the kernel walks the malformed inline directory, a negative bound is promoted to a very large unsigned value, leading f2fs_fill_dentries() to read beyond the inline directory area. The practical impact is kernel memory out-of-bounds read, with potential kernel crash, information disclosure, and possible follow-on memory corruption depending on kernel build, hardening, and execution path.

Why it matters to the business

Systems that mount untrusted F2FS filesystems, such as removable media, disk images, mobile/embedded storage, forensic workflows, virtualization hosts, or automated file-ingestion pipelines, could be crashed or potentially compromised by a malicious filesystem image. Because exploitation is local and requires the malicious image to be mounted or otherwise parsed by the kernel, internet-wide risk is lower than for a remote service bug, but operational impact can still be high for endpoints, appliances, and systems that automatically mount external storage.

How an attack unfolds

An attacker creates a malformed F2FS filesystem image with the flexible_inline_xattr feature enabled and an inode whose i_inline_xattr_size is outside the valid range while the inode layout lacks the FI_INLINE_XATTR flag. The attacker then gets the target system to mount or process that image, for example through removable media, a supplied disk image, a VM/container storage workflow, a forensic analysis pipeline, or any mechanism that causes the Linux kernel F2FS driver to parse the crafted filesystem. When a directory or file using the malformed inline layout is read, the kernel calculates invalid inline data and dentry limits, causing the inline directory traversal to read past the intended in-inode data area. This can result in a kernel oops/panic, memory disclosure in diagnostic contexts, or potentially broader kernel compromise if the out-of-bounds access can be shaped into a useful primitive on a vulnerable build.

How to fix it

Upgrade to a Linux kernel version from the relevant distribution or vendor that includes the F2FS fix validating i_inline_xattr_size whenever flexible_inline_xattr is enabled. No exact fixed package versions were provided in the input, so use the latest security-supported kernel available for the affected distribution, appliance, or embedded platform and confirm the vendor advisory references this fix. As mitigations where immediate patching is not possible, prevent mounting untrusted F2FS filesystems, disable automatic mounting of removable media, restrict mount privileges, block or unload the f2fs kernel module where F2FS is not required, and isolate systems that must analyze untrusted disk images by using disposable VMs or sandboxes with patched kernels.

How to confirm the fix worked

Confirm the running kernel package includes the upstream or vendor patch that bounds i_inline_xattr_size against MAX_INLINE_XATTR_SIZE for flexible_inline_xattr images. Validate exposure by checking whether F2FS support is present or loaded, whether untrusted users or automated services can mount F2FS images, and whether removable-media automounting is enabled. After patching, test with vendor-provided regression coverage or a benign crafted F2FS test image in a lab to confirm the malformed inode is rejected rather than causing a kernel warning, oops, KASAN report, or panic. Confirm all booted kernels, rescue kernels, appliance images, and golden images are updated, not only installed packages.

Typical attack path

1. Create a crafted F2FS filesystem image with flexible_inline_xattr enabled.
2. Set a malicious i_inline_xattr_size value on an inode that does not carry FI_INLINE_XATTR but uses inline directory or inline data layout.
3. Deliver the image to a target that may mount or inspect F2FS filesystems.
4. Cause the vulnerable kernel to mount the image and access the malformed directory or file.
5. Trigger f2fs_fill_dentries() or related F2FS inline-data parsing code.
6. Cause an out-of-bounds kernel read, leading to crash, information exposure, or possible kernel-level impact.

How to detect it

There are no reliable network indicators for this issue because exploitation occurs through local kernel parsing of a crafted F2FS filesystem image. To determine whether exploitation may have occurred, review kernel logs, system journals, crash dumps, and EDR telemetry for F2FS-related kernel oops, panic, KASAN, UBSAN, or general-protection-fault events. Focus on events involving f2fs_fill_dentries(), make_dentry_ptr_inline(), inline directory handling, test_bit_le(), or fs/f2fs/dir.c. Correlate suspicious crashes with recent mount activity, loop-device creation, removable-media insertion, forensic image processing, VM disk attachment, or automated filesystem scanning. Review auditd, sudo, udev, desktop automount, systemd, container runtime, and hypervisor logs for mount operations using type f2fs or loop-mounted images. Preserve any suspicious disk images, removable devices, kernel vmcore files, and journal logs for offline analysis. Absence of logs does not rule out exploitation if kernel crash dumps or persistent journaling were not enabled.

• BUG: KASAN: slab-out-of-bounds in f2fs_fill_dentries
• BUG: KASAN: out-of-bounds in f2fs_fill_dentries
• BUG: KASAN: global-out-of-bounds in f2fs_fill_dentries
• BUG: KASAN: stack-out-of-bounds in f2fs_fill_dentries
• general protection fault in f2fs_fill_dentries
• kernel BUG at fs/f2fs/dir.c
• RIP: 0010:f2fs_fill_dentries
• Call Trace: f2fs_fill_dentries
• make_dentry_ptr_inline
• test_bit_le
• i_inline_xattr_size
• F2FS-fs
• mount -t f2fs
• type=f2fs

What your security team should do

• Prioritize patching systems that mount removable media, process disk images, run forensic tooling, host virtualization/storage workflows, or support F2FS on embedded/mobile platforms.
• Disable or restrict F2FS mounting on systems that do not require it, including removal or blacklist of the f2fs kernel module where operationally safe.
• Disable automatic mounting of removable media and untrusted disk images until kernels are patched.
• Ensure only privileged, trusted administrators can mount filesystems, and review any sudo, udev, desktop, container, or automation paths that may indirectly mount user-supplied images.
• Monitor kernel logs and crash telemetry for F2FS-related oops, panic, KASAN, or out-of-bounds-read reports involving f2fs_fill_dentries(), inline dentries, or fs/f2fs/dir.c.
• Perform forensic review of recent removable-media mounts, loop-device mounts, disk-image analysis jobs, and unexplained kernel crashes on systems with F2FS enabled.
• Update base images, live media, recovery environments, and embedded firmware kernels, since older auxiliary boot environments may remain vulnerable even after the primary OS is patched.