CVE-2026-53018

What it actually does

This is a Linux kernel F2FS filesystem flaw in garbage collection handling. Under specific timing and filesystem-state conditions, F2FS may re-read a page that has already been moved and marked up to date during garbage collection. That inconsistent page-cache state can trigger a kernel BUG assertion in the filemap read-completion path, causing a kernel crash or system panic. The practical technical impact is denial of service on systems that mount and use affected F2FS filesystems; there is no indication from the provided data that this enables privilege escalation, code execution, or data disclosure.

Why it matters to the business

Systems using F2FS-backed storage may crash unexpectedly if the vulnerable garbage-collection path is triggered, causing service interruption, device reboot, workload failure, or potential availability loss for embedded, mobile, appliance, or storage-constrained Linux systems that rely on F2FS. The EPSS score is very low and the issue is not listed in CISA KEV, so broad active exploitation is not currently indicated, but the kernel-level crash risk still matters for high-availability systems or products that automatically mount untrusted removable media or disk images.

How an attack unfolds

An attacker would need a way to make a vulnerable Linux system mount and exercise an F2FS filesystem that can trigger the faulty garbage-collection sequence. In a local attack scenario, this could involve a user or process creating or mounting a specially prepared F2FS image and performing file operations that force garbage collection, data movement, and read completion ordering that exposes the stale page-state condition. In a removable-media or image-processing scenario, the attacker could supply crafted storage media or a filesystem image to a system that automatically mounts or scans it. Once the vulnerable path is reached, F2FS may initiate an unnecessary read for a page already marked up to date, leading to a VM_BUG_ON_FOLIO assertion and a kernel BUG in mm/filemap.c, typically resulting in a crash or panic rather than attacker-controlled execution.

How to fix it

Upgrade to a Linux kernel build that includes the upstream F2FS fix for this issue. Because no product-specific affected versions or fixed versions were provided, use the kernel packages supplied by the relevant Linux distribution, device vendor, or appliance vendor and confirm that their advisory explicitly includes the fix for this vulnerability or the associated F2FS change to avoid reading already updated pages during garbage collection. Where immediate patching is not possible, reduce exposure by avoiding F2FS on systems that do not require it, disabling automatic mounting of removable media or untrusted disk images, restricting mount privileges to trusted administrators, and using hardened mount workflows for externally supplied storage.

How to confirm the fix worked

Confirm the running kernel has been updated to a vendor release that contains the F2FS garbage-collection fix. Validate with the distribution or vendor advisory rather than relying only on upstream kernel version numbers, because fixes may be backported. Inventory systems for mounted F2FS filesystems using commands such as findmnt -t f2fs, mount | grep f2fs, or filesystem inventory tooling. After patching, reboot into the fixed kernel and verify with uname -a and package-manager records that the active kernel is the updated one. For exposure validation, confirm that untrusted users cannot mount F2FS filesystems and that automatic mounting of removable F2FS media or disk images is disabled where not required.

Typical attack path

1. Identify a Linux system running a kernel version with the vulnerable F2FS garbage-collection code.
2. Obtain local access or another path that causes the target to mount or process an F2FS filesystem, such as removable media, a disk image, or a managed storage volume.
3. Prepare or manipulate an F2FS filesystem so garbage collection moves pages through the affected sequence.
4. Trigger filesystem activity that forces F2FS garbage collection and read completion on the affected page state.
5. Cause the kernel BUG assertion to fire, resulting in a crash, panic, or service disruption.

How to detect it

Look for evidence of kernel crashes or panics associated with F2FS garbage collection and filemap read completion. Useful sources include dmesg output, journalctl -k, /var/log/kern.log, /var/log/messages, crash dumps, kdump/vmcore records, hypervisor reset events, device watchdog reset logs, and EDR telemetry that captures kernel oops or panic messages. Search for stack traces containing F2FS garbage-collection functions such as do_garbage_collect, f2fs_gc, gc_thread_func, f2fs_finish_read_bio, or f2fs_read_end_io together with VM_BUG_ON_FOLIO or kernel BUG at mm/filemap.c. Also investigate unusual mount events for F2FS filesystems, especially from removable devices, loop-mounted images, containers with elevated privileges, or recently attached block devices preceding a crash. Because exploitation would likely result in denial of service rather than durable malware artifacts, absence of file-based IOCs does not rule out attempted triggering; timeline correlation between F2FS mount/activity and kernel panic is the most useful detection approach.

• VM_BUG_ON_FOLIO(folio_test_uptodate(folio))
• kernel BUG at mm/filemap.c:1563
• folio_end_read
• f2fs_finish_read_bio
• f2fs_read_end_io
• do_garbage_collect
• f2fs_gc
• gc_thread_func
• f2fs_meta_aops
• page dumped because: VM_BUG_ON_FOLIO
• mount -t f2fs
• type f2fs

What your security team should do

• Prioritize patching Linux systems that use F2FS for production storage, embedded storage, mobile-style flash storage, or removable-media workflows.
• Inventory where F2FS is enabled or mounted, including appliances, edge devices, test systems, and image-processing hosts.
• Restrict filesystem mounting privileges and disable automatic mounting of untrusted removable media or disk images until patched.
• Monitor kernel logs for F2FS garbage-collection crashes, VM_BUG_ON_FOLIO messages, and kernel BUG reports in mm/filemap.c.
• Treat repeated unexplained kernel panics on F2FS systems as potentially security-relevant until logs confirm a benign operational cause.
• Track distribution and vendor advisories for backported kernel fixes because exact fixed package versions were not provided in the input.