CVE-2026-53388

What it actually does

This is a Linux kernel use-after-free vulnerability in the FUSE filesystem request handling path. The vulnerable logic in fuse_try_move_folio() unlocks a request and, on the successful page-cache folio replacement path, fails to re-lock it before later copy-chain logic continues using the associated fuse_io_args structure. A concurrent abort path such as fuse_chan_abort() can complete and free those I/O arguments while they are still being referenced, creating a race condition that may lead to memory corruption in kernel context. Because exploitation occurs in the kernel and the CVSS vector is local, low-complexity, and requires low privileges, a successful attacker could potentially crash the system or achieve local privilege escalation with kernel-level confidentiality, integrity, and availability impact.

Why it matters to the business

Systems that allow untrusted or low-privileged users to interact with FUSE mounts are at elevated risk because a local user may be able to turn a filesystem race condition into a system crash or privilege escalation. The most likely operational impact is host instability, denial of service, or compromise of workloads running on affected Linux kernels. Although there is no known CISA KEV listing, no known ransomware association, and EPSS is currently low, kernel vulnerabilities with local privilege-escalation potential should still be prioritized on shared servers, developer workstations, container hosts, VDI platforms, and multi-user Linux systems.

How an attack unfolds

An attacker first needs local code execution as a low-privileged user on a vulnerable Linux system with access to FUSE functionality or a workload that exercises FUSE read/page-cache behavior. The attacker then triggers a race in the FUSE read path where fuse_try_move_folio() succeeds after unlocking the request, while another execution path aborts the FUSE channel and frees the associated fuse_io_args. If the timing is won, later kernel copy logic continues to access freed memory. Depending on kernel configuration, heap layout, hardening features, and exploit reliability, this can result in a kernel oops/panic or potentially controlled memory corruption that enables privilege escalation. There is no public exploit maturity reported in the provided data, so exploitation should be treated as plausible but not currently commoditized.

How to fix it

Apply the Linux kernel update from the relevant distribution or kernel vendor that includes the FUSE fix which re-locks the request before replace_page_cache_folio() on the successful fuse_try_move_folio() path. Because no exact affected product list or fixed package versions were provided, use vendor advisories for the deployed distribution, cloud image, appliance, or embedded platform to identify the corrected kernel build. Reboot into the patched kernel after installation; merely installing the package is insufficient if the running kernel remains vulnerable. Where immediate patching is not possible, reduce exposure by restricting untrusted local shell access, limiting use of FUSE to trusted users, disabling or removing unnecessary FUSE mounts, reviewing permissions around fusermount/fusermount3, and applying host hardening controls such as kernel lockdown, LSM policies, and container isolation. Mitigations should be treated as temporary because the flaw is in kernel memory-safety logic.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel, not just the installed kernel package, is at or above the vendor-fixed build. Use commands such as uname -a, package manager queries, and vendor advisory mappings to confirm the active kernel includes the FUSE patch. Validate that systems were rebooted after patching and that no older vulnerable kernel remains selected by default in the bootloader. If kernel live patching is used, confirm the live patch specifically covers this FUSE change. For exposure validation, check whether FUSE is enabled or loaded, whether /dev/fuse exists, whether fuse or fuse3 packages are installed, and whether unprivileged users are permitted to mount FUSE filesystems. Practical security validation should focus on patch presence and configuration review rather than attempting exploit reproduction on production systems.

Typical attack path

1. Obtain local, low-privileged access to a vulnerable Linux host.
2. Identify whether FUSE support is available and whether the user can create or interact with FUSE mounts.
3. Create or manipulate FUSE filesystem activity that exercises readpages/page-cache folio replacement behavior.
4. Race normal FUSE request processing against FUSE channel abort or teardown behavior.
5. Trigger use-after-free access to fuse_io_args during subsequent kernel copy-chain logic.
6. Cause a denial-of-service condition through kernel crash, or attempt to shape freed kernel memory for privilege escalation.
7. If privilege escalation succeeds, execute code with elevated or root-level privileges on the host.

How to detect it

Detection of prior exploitation is difficult because successful exploitation would occur through a kernel race condition and may not leave a clean application-level audit trail. Focus on kernel telemetry, crash artifacts, authentication history, process execution logs, and FUSE mount activity. Review dmesg, journald, syslog, kern.log, auditd, EDR telemetry, crash dumps, kdump/vmcore data, and KASAN/KMSAN reports for use-after-free, kernel oops, panic, or general protection fault messages referencing FUSE code paths such as fuse_try_move_folio(), fuse_chan_abort(), fuse_readpages_end(), replace_page_cache_folio(), or page-cache folio replacement. Investigate unexplained host reboots or crashes followed by suspicious privilege changes, new root-owned files, setuid binaries, kernel exploit tooling, abnormal fusermount/fusermount3 execution, or unusual mount/unmount loops by low-privileged users. Because no public exploit or threat actor activity is indicated in the provided data, detections should combine function-name crash indicators with behavioral signs of local privilege escalation rather than rely on a single static IOC.

• fuse_try_move_folio
• fuse_chan_abort
• fuse_readpages_end
• replace_page_cache_folio
• use-after-free in fuse
• KASAN: use-after-free
• BUG: KASAN: use-after-free
• general protection fault
• kernel BUG at fs/fuse
• kernel panic - not syncing
• Oops:
• /dev/fuse
• fusermount
• fusermount3
• mount.fuse
• mount.fuse3

What your security team should do

• Inventory Linux systems that permit local user access, container workloads, developer access, or FUSE-based filesystems, and prioritize those for kernel patching.
• Patch affected Linux kernels using distribution or vendor-provided fixed builds, then reboot and verify the running kernel version.
• Prioritize shared multi-user systems, CI/CD runners, bastion hosts, VDI hosts, container hosts, and systems where untrusted users can invoke FUSE.
• Temporarily restrict FUSE usage to trusted administrators where business operations allow, especially on systems that cannot be patched quickly.
• Monitor kernel logs for FUSE-related crashes, KASAN use-after-free reports, general protection faults, or kernel oops messages involving FUSE functions.
• Review local privilege-escalation detections around suspicious compilation, exploit staging, abnormal FUSE mount activity, and unexpected root shells spawned by formerly low-privileged users.
• Do not rely on the low EPSS score alone for prioritization; local kernel privilege-escalation bugs can be highly impactful in shared or post-compromise environments.