CVE-2026-53311

What it actually does

This is a Linux kernel FUSE flaw in fuse_dentry_revalidate() where the kernel may read an uninitialized dentry timestamp field during file lookup/open handling. At a technical level, the bug creates undefined kernel behavior and can expose or act on stale kernel memory state when FUSE-backed paths are revalidated. The issue is most relevant to local attack surfaces where an attacker can create, mount, or interact with FUSE filesystems, including systems that allow unprivileged FUSE usage or container workloads with access to /dev/fuse.

Why it matters to the business

Successful exploitation could allow a local user or compromised workload to obtain sensitive information from kernel memory or destabilize file-access behavior on affected Linux systems. The operational risk is highest on multi-user servers, developer workstations, container hosts, shared compute platforms, and environments that allow user-controlled FUSE mounts. The CVE is not currently in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS, and has no reported public exploit maturity, so remediation should be prioritized through normal kernel patch cycles unless FUSE is broadly enabled for untrusted users.

How an attack unfolds

An attacker first obtains local code execution or an account on a vulnerable Linux system. They then interact with a FUSE filesystem, either by mounting a user-controlled FUSE filesystem where permitted or by accessing an existing FUSE-backed path. By performing file lookup and open operations that force dentry revalidation, the attacker can trigger the vulnerable fuse_dentry_revalidate() path before the dentry time field has been initialized. The kernel then consumes uninitialized memory during the validation logic. Depending on kernel build, allocator state, and surrounding code paths, this may result in disclosure of stale kernel memory-derived values, incorrect cache/revalidation decisions, or diagnostic kernel reports such as KMSAN warnings. There is no strong evidence of remote exploitation or active exploitation in the wild from the provided data.

How to fix it

Upgrade to a Linux kernel version or vendor kernel package that includes the FUSE fix for uninitialized dentry time handling in fuse_dentry_revalidate(). Because no exact fixed versions were provided, use distribution security advisories and kernel changelogs to identify the corrected package for each supported operating system. Where immediate patching is not possible, reduce exposure by disabling or restricting unprivileged FUSE mounts, limiting access to /dev/fuse, removing unnecessary FUSE tooling from sensitive systems, preventing containers from receiving /dev/fuse unless required, and avoiding broad CAP_SYS_ADMIN or mount privileges for untrusted workloads. Reboot systems after kernel updates to ensure the fixed kernel is running.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel, not just the installed package, is a vendor-fixed build using uname -r and the distribution package manager. Review vendor advisories or source patches for the FUSE change that ensures the relevant dentry time field is initialized or safely handled before fuse_dentry_revalidate() consumes it. Validate that unprivileged users cannot mount FUSE filesystems unless this is intentionally required. On test systems, run regression or vendor kernel self-tests involving FUSE lookup/open operations and confirm there are no KMSAN, KASAN, or kernel warning reports referencing fuse_dentry_revalidate().

Typical attack path

1. Gain local execution on an affected Linux host, container host, or shared system.
2. Determine whether FUSE is available by checking for /dev/fuse, fusermount/fusermount3, or existing FUSE mounts.
3. Create or access a FUSE-backed filesystem path that the attacker can control or repeatedly query.
4. Trigger lookup/open operations that cause dentry allocation followed by d_revalidate() and fuse_dentry_revalidate().
5. Attempt to observe information disclosure effects, stale validation behavior, crashes, or kernel diagnostic output.
6. Use any disclosed information to support further local privilege escalation, sandbox escape research, or reconnaissance.

How to detect it

There is no reliable network-level signature for this issue, and exploitation may leave little or no application-level evidence because the vulnerable behavior occurs inside the kernel during FUSE path lookup. To look for prior triggering or attempted exploitation, review kernel logs from dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, and crash reporting systems for KMSAN or kernel warning traces that reference fuse_dentry_revalidate(), fs/fuse/dir.c, lookup_open(), open_last_lookups(), path_openat(), or uninitialized-value reports. Review auditd, EDR, shell history, and process execution logs for unexpected use of /dev/fuse, fusermount, fusermount3, mount.fuse, or unusual user-controlled FUSE mounts. On container hosts, inspect runtime events for containers granted /dev/fuse or elevated mount capabilities. Because these indicators can also occur during legitimate FUSE use or kernel testing, correlate findings with user identity, timing, mount source, command line, container privileges, and any subsequent suspicious local activity.

• BUG: KMSAN: uninit-value in fuse_dentry_revalidate
• fuse_dentry_revalidate
• fs/fuse/dir.c:394
• d_revalidate fs/namei.c:1030
• lookup_open fs/namei.c:4405
• open_last_lookups fs/namei.c:4583
• path_openat+
• do_file_open+
• __d_alloc fs/dcache.c:1740
• d_alloc_parallel fs/dcache.c:2604
• /dev/fuse
• fusermount
• fusermount3
• mount.fuse
• KMSAN: uninit-value

What your security team should do

• Inventory Linux systems where FUSE is installed, enabled, or exposed to untrusted users and containers.
• Patch affected Linux kernels through the normal security update process, prioritizing shared systems, container hosts, developer workstations, and multi-tenant compute platforms.
• Restrict /dev/fuse access and unprivileged FUSE mounting where there is no business requirement.
• Review container and sandbox configurations for unnecessary /dev/fuse passthrough, CAP_SYS_ADMIN, or mount privileges.
• Monitor kernel logs for KMSAN or kernel warning traces involving fuse_dentry_revalidate(), lookup_open(), or FUSE dentry revalidation.
• Treat suspicious FUSE activity by untrusted users as a local post-compromise signal and investigate for broader host compromise.