CVE-2026-63819

What it actually does

This is a Linux kernel flaw in the F2FS filesystem driver. A malformed or corrupted F2FS filesystem image can contain an inconsistent inode-to-node relationship where a direct node is incorrectly accepted as if it were valid. During operations such as mount, inode eviction, or truncation, the kernel reaches f2fs_do_truncate_blocks(), calculates an invalid node address range, and hits a kernel BUG condition. The practical result is a local kernel crash/panic and denial of service. Because the failure occurs in kernel filesystem parsing logic, exploitation requires the system to process a crafted F2FS filesystem, typically by mounting it or otherwise allowing the kernel F2FS driver to inspect it.

Why it matters to the business

Systems that mount untrusted F2FS media or filesystem images can be crashed by a low-privileged local user or by an attacker who can cause a crafted F2FS image to be mounted. This can interrupt workloads, cause host reboots, disrupt embedded/mobile/storage devices that use F2FS, and create operational downtime. The vulnerability is not currently listed in CISA KEV, is not known to be used in ransomware, and has a very low EPSS score, so broad internet-scale exploitation is unlikely; however, the impact is important for multi-user Linux systems, device fleets, CI/sandbox environments, and platforms that automatically mount removable or user-supplied filesystems.

How an attack unfolds

An attacker prepares a malformed F2FS filesystem image with a corrupted inode/node chain, specifically causing a direct node footer to appear inconsistent with the expected node type. The attacker then needs the target Linux system to process that image with the vulnerable F2FS driver. This may happen if the attacker has local access and mount privileges, can influence an automated mount workflow, can provide removable media, or can submit disk images to a service that mounts or validates them. When the image is mounted or when cleanup/truncation paths run, F2FS follows the malformed node chain into f2fs_get_node_folio_ra() and related node lookup logic. Without the added sanity check, the kernel accepts the inconsistent node, reaches f2fs_do_truncate_blocks(), calculates an invalid address count/offset relationship, and triggers a BUG_ON condition. The kernel then emits an Oops/invalid opcode and may panic or crash, causing denial of service.

How to fix it

Update the Linux kernel to a vendor-supported version that includes the upstream F2FS fix titled "f2fs: fix to do sanity check on f2fs_get_node_folio_ra()". If exact fixed package versions are not available from the vulnerability record, use the relevant Linux distribution, appliance, mobile/embedded vendor, or kernel maintainer advisory to identify the patched kernel build. Where immediate patching is not possible, reduce exposure by disabling F2FS support if it is not required, blacklisting the f2fs kernel module where it is modular, preventing unprivileged users from mounting filesystems, disabling automount of removable media or disk images, and avoiding automated mounting of untrusted F2FS images in CI, malware-analysis, support, or file-processing pipelines.

How to confirm the fix worked

Confirm that systems are running a kernel build that contains the F2FS sanity-check patch. Validate through vendor package metadata, changelogs, kernel source/backport notes, or distribution advisories rather than relying only on the upstream kernel version string, because fixes are often backported. Check whether F2FS is enabled or loaded by reviewing kernel configuration and module state, such as CONFIG_F2FS_FS, loaded f2fs modules, and active F2FS mounts. After patching, reboot into the updated kernel and verify that the previous vulnerable kernel is not still in use. In a controlled non-production lab, a known malformed F2FS test image should be rejected or fail safely without producing a kernel BUG or panic.

Typical attack path

1. Create or obtain a malformed F2FS filesystem image containing a corrupted inode and inconsistent direct node footer.
2. Deliver the image to a Linux system that has vulnerable F2FS support enabled.
3. Cause the image to be mounted or inspected by the kernel F2FS driver, either directly through local mount access or indirectly through an automated workflow.
4. Trigger filesystem paths such as mount, inode eviction, or file truncation that call f2fs_get_dnode_of_data() and f2fs_do_truncate_blocks().
5. The vulnerable kernel fails to reject the inconsistent node chain and hits a kernel BUG condition.
6. The system logs an Oops/invalid opcode and may panic or reboot, resulting in denial of service.

How to detect it

To determine whether this was already exploited or triggered, review kernel logs, persistent journals, crash dumps, and system reboot records for F2FS-related kernel BUG/Oops events. Relevant sources include dmesg output, /var/log/kern.log, /var/log/messages, systemd-journald kernel entries, kdump/vmcore repositories, crash reporting systems, hypervisor reset logs, and EDR telemetry that captures kernel panics or unexpected reboots. Look for crashes occurring immediately after mount activity, loop-device attachment, removable-media insertion, CI disk-image processing, or filesystem validation jobs. Correlate events with audit logs or shell history showing mount, losetup, udisks, systemd-mount, or container runtime activity involving F2FS images. Because this vulnerability does not create a stable user-space artifact, detection is primarily based on kernel crash signatures and suspicious mounting of untrusted F2FS filesystems.

• kernel BUG at fs/f2fs/file.c:845
• f2fs_do_truncate_blocks
• f2fs_truncate_blocks
• f2fs_truncate
• f2fs_evict_inode
• f2fs_fill_super
• f2fs_get_node_folio_ra
• f2fs_get_dnode_of_data
• f2fs_sanity_check_node_footer
• Oops: invalid opcode
• Comm: syz
• ADDRS_PER_PAGE(dn.node_folio, inode)
• f2fs_bug_on

What your security team should do

• Prioritize patching Linux systems that allow local users, containers, build jobs, test harnesses, or automation to mount or inspect filesystem images.
• Inventory systems with F2FS enabled, loaded, or actively mounted, especially embedded, mobile, storage, and removable-media handling environments.
• Disable or restrict F2FS support on systems that do not require it.
• Disable automount behavior for removable media and untrusted disk images until patched.
• Restrict mount capabilities to trusted administrators and review container/sandbox configurations that expose mount operations or loop devices.
• Monitor kernel logs for F2FS-related Oops, BUG, panic, or invalid opcode messages that may indicate attempted exploitation or fuzzing activity.
• Ensure crash collection, kernel panic handling, and service restart procedures are in place for systems where immediate kernel updates are delayed.