CVE-2026-53168

What it actually does

This is an improper input validation flaw in the Linux kernel FUSE implementation. FUSE_NOTIFY_STORE and FUSE_NOTIFY_RETRIEVE allow a user-space FUSE daemon to write to or read from kernel page cache contents. For directories opened with FOPEN_CACHE_DIR, that page cache is intended to be kernel-internal cache storage rather than directly controlled by user space. Before the fix, the kernel did not reject these notify operations when applied to directories, allowing a malicious or compromised FUSE daemon to place unexpected data into the directory cache or retrieve cache contents. The known failure mode is kernel warning paths such as fuse_parse_cache() encountering bogus cached directory data, with likely local denial-of-service or kernel instability impact rather than demonstrated remote code execution.

Why it matters to the business

Systems that allow untrusted users, containers, sandboxed workloads, or third-party software to run FUSE filesystems may be exposed to local disruption if a malicious FUSE daemon abuses this kernel behavior. Operational impact is most likely service instability, kernel warnings, workload interruption, or node reboot depending on kernel hardening and panic-on-warning settings. The public exploitation signal is currently low: EPSS is 0.00123, it is not listed in CISA KEV, is not known to be used in ransomware campaigns, and no public exploit maturity is indicated. Even so, kernel flaws should be prioritized on multi-user Linux systems, container hosts, developer workstations, and platforms where unprivileged FUSE mounts are enabled.

How an attack unfolds

An attacker first needs local code execution with the ability to run or control a FUSE daemon and create or interact with a FUSE mount. The attacker implements or modifies a FUSE filesystem so that directory caching is enabled, then issues FUSE_NOTIFY_STORE or FUSE_NOTIFY_RETRIEVE operations against a directory instead of a regular file. On vulnerable kernels, the request is accepted even though directory page cache contents are meant to be kernel-private. By injecting malformed directory cache data or retrieving cache contents, the attacker can force kernel code that parses the cached directory entries to encounter unexpected state. In practical terms, this can produce kernel WARN_ON conditions and may cause service disruption, especially where kernel warnings are configured to escalate to panic or where repeated triggering destabilizes workloads. Patched kernels reject these operations on non-regular files with EINVAL, stopping the attack before page cache manipulation occurs.

How to fix it

Apply the vendor kernel update that contains the FUSE fix rejecting FUSE_NOTIFY_STORE and FUSE_NOTIFY_RETRIEVE for anything other than regular files. Where exact fixed package versions are not available, update to the latest supported kernel from the operating system vendor or distribution security channel and reboot into the patched kernel. As interim mitigation, restrict FUSE usage to trusted users and services, disable unprivileged FUSE mounts where operationally feasible, review container and sandbox policies that expose /dev/fuse, and avoid running untrusted FUSE filesystem implementations. On high-risk multi-user systems, consider tightening access to fusermount/fusermount3 and monitoring or limiting FUSE mounts until patched.

How to confirm the fix worked

Confirm the running kernel includes the vendor patch for the FUSE change that rejects page-cache notify operations on directories with EINVAL. Validate by checking the active kernel version after reboot, not only the installed package version. On source-based or custom kernels, confirm the FUSE notify path rejects FUSE_NOTIFY_STORE and FUSE_NOTIFY_RETRIEVE unless the target inode is a regular file. Operationally, verify that untrusted users cannot mount FUSE filesystems unless explicitly required. Review kernel logs after patching to ensure there are no recurring WARN_ON traces involving FUSE directory cache parsing, and test representative FUSE workloads to confirm normal mounts and file operations continue to function.

Typical attack path

1. Gain local execution on a Linux system where FUSE use is permitted.
2. Start or compromise a user-space FUSE daemon and mount a FUSE filesystem.
3. Open or operate on a directory using directory caching behavior such as FOPEN_CACHE_DIR.
4. Send FUSE_NOTIFY_STORE or FUSE_NOTIFY_RETRIEVE requests targeting the directory rather than a regular file.
5. Manipulate or retrieve directory page cache contents that should be kernel-internal.
6. Trigger kernel directory-cache parsing on the malformed cached data.
7. Cause kernel warnings, instability, or denial-of-service conditions on vulnerable kernels.

How to detect it

Evidence of exploitation is most likely visible in host telemetry rather than network logs, because exploitation requires local interaction with a FUSE daemon. Review kernel logs from journald, syslog, dmesg, crash logs, and centralized EDR telemetry for WARN_ON traces or call stacks involving FUSE directory cache parsing, particularly fuse_parse_cache. Look for suspicious or unexpected FUSE mounts in mount audit logs, process execution telemetry, shell history, and auditd events involving fusermount, fusermount3, mount.fuse, or custom FUSE daemons. On container platforms, inspect workloads that were granted access to /dev/fuse or SYS_ADMIN-like privileges and correlate with host kernel warnings or reboots. If kernel panic-on-warn is enabled, investigate unexplained panics or node reboots with FUSE functions in the stack trace. There are no known public threat actors or ransomware campaigns associated with this issue based on the provided data.

• fuse_parse_cache
• FUSE_NOTIFY_STORE
• FUSE_NOTIFY_RETRIEVE
• FOPEN_CACHE_DIR
• fusermount
• fusermount3
• mount.fuse
• /dev/fuse
• WARNING: CPU:
• kernel: WARNING
• fs/fuse/

What your security team should do

• Patch Linux kernels through the relevant distribution or vendor channel and reboot affected systems, prioritizing multi-user servers, container hosts, virtualization hosts, developer workstations, and systems that expose /dev/fuse.
• Inventory where FUSE is enabled, including packages and services using fusermount, fusermount3, mount.fuse, sshfs, rclone, AppImage, sandboxing tools, and container workloads.
• Restrict unprivileged FUSE mounts where they are not business-critical, and limit /dev/fuse exposure inside containers or sandboxes.
• Hunt kernel logs for FUSE-related WARN_ON traces, especially entries containing fuse_parse_cache or FUSE directory cache parsing failures.
• Review recent creation of unusual FUSE mounts and executions of custom or unsigned FUSE daemons by non-administrative users.
• Do not treat the low EPSS and non-KEV status as a reason to defer indefinitely; kernel-local denial-of-service flaws can still be material in shared compute environments.