CVE-2026-63816

What it actually does

This is a Linux kernel use-after-free vulnerability in the F2FS filesystem atomic file handling path. During F2FS garbage collection, the kernel can access the mapping field of an atomic inode after that inode has been evicted and freed. A local user who can interact with an affected F2FS filesystem and trigger the relevant ioctl and garbage-collection behavior may be able to cause kernel memory corruption. Depending on exploitability on a given kernel build and configuration, impact can include local privilege escalation, kernel crash, data corruption, or arbitrary kernel-code execution.

Why it matters to the business

Systems using affected Linux kernel versions with F2FS-mounted storage are at risk of local users or compromised low-privilege processes escalating privileges or crashing the host. This is most relevant for Linux servers, embedded devices, Android-derived systems, appliances, and storage devices that use F2FS. Although the vulnerability is not currently listed in CISA KEV, has very low EPSS, and has no known public exploit maturity in the provided data, the high CVSS impact means exposed multi-user or containerized systems should still be patched through normal kernel maintenance windows.

How an attack unfolds

An attacker first needs local code execution or an account on a system running an affected Linux kernel with an F2FS filesystem. The attacker then creates or manipulates F2FS files that use the atomic write/copy-on-write path and triggers F2FS garbage collection, including the F2FS_IOC_GARBAGE_COLLECT_RANGE ioctl path. By racing garbage collection against inode eviction, the vulnerable code can dereference the atomic_inode mapping after the inode has been released. Successful exploitation would require shaping kernel heap state so that the stale pointer access produces controlled memory corruption rather than only a crash. In practical terms, exploitation is local and kernel-version-specific, but a successful exploit could convert limited local access into root-level control of the host.

How to fix it

Upgrade the Linux kernel to a vendor-supported release that includes the F2FS fix adding a valid reference to atomic_inode before its mapping is used during garbage collection. Because no exact fixed package versions were provided, use the fixed kernel versions published by the relevant Linux distribution, device vendor, or appliance vendor. Where immediate patching is not possible, reduce exposure by disabling or avoiding F2FS where operationally feasible, remounting or migrating affected F2FS filesystems, restricting local shell access, limiting untrusted workloads, and applying least-privilege controls that prevent untrusted users from creating or manipulating files on F2FS volumes. Reboot after installing the fixed kernel so the patched kernel is actually running.

How to confirm the fix worked

Confirm the running kernel version, not only the installed package version, after remediation. Verify vendor advisories or kernel changelogs show the F2FS atomic_inode use-after-free fix is included. Inventory mounted filesystems with tools such as findmnt, mount, or /proc/mounts and confirm whether F2FS is present. If F2FS is not used, exposure is substantially reduced. If F2FS is used, validate that systems have rebooted into the fixed kernel and that no older vulnerable kernels remain as the default boot option. For high-assurance validation, review the kernel source or vendor patch set for the change in the F2FS garbage-collection path that obtains a reference on fi->atomic_inode before using its i_mapping field.

Typical attack path

1. Gain local code execution or low-privileged shell access on a Linux system using an affected kernel.
2. Confirm that an F2FS filesystem is mounted and accessible for file creation or manipulation.
3. Create files that exercise F2FS atomic file or copy-on-write behavior.
4. Trigger F2FS garbage collection, including via the F2FS_IOC_GARBAGE_COLLECT_RANGE ioctl path where permitted.
5. Race garbage collection against eviction of the associated atomic inode.
6. Cause a stale atomic_inode mapping reference to be used after free.
7. Leverage resulting kernel memory corruption for privilege escalation, or cause a denial-of-service kernel panic if exploitation is unreliable.

How to detect it

Look for evidence of attempted exploitation in kernel logs and host telemetry. Relevant sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, auditd syscall logs, EDR process telemetry, crash dumps, kdump/vmcore artifacts, and filesystem activity on F2FS mount points. Indicators include kernel warnings or panics involving F2FS garbage collection, atomic inode handling, use-after-free, KASAN reports, BUG_ON failures in inode cleanup, or crashes near truncate_inode_pages_final, clear_inode, f2fs_gc, gc_data_segment, ra_data_block, or f2fs_grab_cache_folio. Also review local user activity around the time of crashes for binaries repeatedly invoking ioctl operations against F2FS files, unusual file churn on F2FS volumes, or repeated garbage-collection triggering. Because no public exploit artifacts are provided, detection should focus on behavioral evidence and kernel crash signatures rather than known malware indicators.

• F2FS_IOC_GARBAGE_COLLECT_RANGE
• f2fs_gc
• gc_data_segment
• ra_data_block
• f2fs_grab_cache_folio
• f2fs_evict_inode
• truncate_inode_pages_final
• clear_inode
• BUG_ON
• i_data.nrpages
• use-after-free
• KASAN: use-after-free
• kernel BUG
• F2FS-fs
• FI_COW_FILE
• atomic_inode
• cow_inode

What your security team should do

• Prioritize patching systems that use F2FS and allow local users, containers, build jobs, shared hosting workloads, mobile workloads, or other untrusted code execution.
• Inventory Linux assets for mounted F2FS filesystems and affected kernel versions.
• Apply vendor kernel updates and reboot into the fixed kernel; verify the running kernel after reboot.
• Where patching is delayed, restrict local access to systems with F2FS, reduce untrusted workload placement, and consider disabling or migrating F2FS volumes where feasible.
• Monitor kernel logs for F2FS garbage-collection errors, use-after-free reports, KASAN warnings, BUG_ON messages, or unexpected kernel panics.
• Treat suspicious kernel crashes on F2FS systems as potential exploitation attempts, especially if preceded by unusual local user activity or repeated ioctl-driven filesystem operations.
• Ensure endpoint and workload isolation controls prevent a compromise of a low-privilege account or container from becoming a broader host compromise.