CVE-2026-53167

What it actually does

This Linux kernel flaw allows FUSE_NOTIFY_RETRIEVE to return data from folios that are present in the page cache but not marked uptodate. Because non-uptodate folios may contain uninitialized kernel memory, a local attacker who can operate or influence a FUSE filesystem daemon may be able to read stale memory contents that should not be exposed. The security impact is primarily information disclosure and is materially reduced on systems that enable automatic zero-initialization of page allocations through CONFIG_INIT_ON_ALLOC_DEFAULT_ON or the boot option init_on_alloc=1.

Why it matters to the business

Successful exploitation could expose sensitive data resident in kernel memory, such as fragments of files, credentials, tokens, cryptographic material, or data from other processes, depending on memory reuse patterns. The practical risk is lower than many remotely exploitable kernel bugs because exploitation appears to require local FUSE capabilities and there is no known public exploit or CISA KEV listing, with a low EPSS score. However, systems that allow unprivileged FUSE mounts or host multi-user workloads have higher exposure because an untrusted local user may have a viable path to interact with FUSE.

How an attack unfolds

An attacker first obtains local access to a Linux system where FUSE is available and where they can mount or control a FUSE filesystem, or they compromise an existing FUSE daemon. They then arrange for relevant page-cache folios associated with the FUSE-backed file to be present but not uptodate. By issuing or influencing FUSE_NOTIFY_RETRIEVE behavior, the attacker causes the kernel to retrieve data from those folios instead of treating them as absent. On vulnerable kernels, the kernel may return bytes from uninitialized memory rather than valid file contents. The attacker repeats the operation to collect memory fragments and analyzes the returned data for secrets or sensitive process/file remnants. Systems with init-on-allocation memory clearing enabled are significantly less likely to expose useful data because newly allocated pages are zeroed.

How to fix it

Apply the vendor-provided Linux kernel update that includes the FUSE fix limiting FUSE_NOTIFY_RETRIEVE to uptodate folios. Because no universal fixed package versions were provided, use the fixed kernel builds from the relevant Linux distribution or kernel vendor and reboot into the updated kernel. As defense in depth, enable automatic page-allocation zeroing by building with CONFIG_INIT_ON_ALLOC_DEFAULT_ON or booting with init_on_alloc=1 where performance impact is acceptable. Restrict unprivileged FUSE usage where it is not required, review permissions on fusermount/fusermount3, limit users allowed to create FUSE mounts, and disable or remove FUSE support on systems that do not need it.

How to confirm the fix worked

Confirm the running kernel is the updated vendor-fixed build, not merely that an updated package is installed. Validate with commands such as uname -a, package-manager kernel inventory, and distribution security advisories for this CVE. Check whether the mitigation is active by reviewing the kernel command line for init_on_alloc=1 and, where applicable, kernel configuration for CONFIG_INIT_ON_ALLOC_DEFAULT_ON. Confirm whether FUSE is loaded or available with lsmod, /proc/filesystems, and the presence of /dev/fuse. On systems where FUSE is not required, validate that unprivileged users cannot create FUSE mounts. There is no reliable remote scanner-only proof of non-exploitability; validation should combine kernel version, booted configuration, and FUSE exposure review.

Typical attack path

1. Gain local shell access or code execution on a Linux system.
2. Confirm that FUSE is available and that the attacker can mount, control, or interact with a FUSE filesystem daemon.
3. Create or manipulate a FUSE-backed file and page-cache state so that folios are present but not uptodate.
4. Trigger FUSE_NOTIFY_RETRIEVE against the target file range.
5. Receive data returned by the kernel that may include uninitialized memory rather than legitimate cached file data.
6. Search recovered bytes for sensitive information such as credentials, tokens, keys, or fragments of other workloads.
7. Use any recovered secrets to escalate access or move laterally if valuable data is exposed.

How to detect it

Retrospective detection is difficult because exploitation may only return memory contents through legitimate FUSE kernel interfaces and may not generate a unique kernel log entry. Review auditd, EDR, shell history, process execution logs, and authentication logs for unexpected local users running fusermount, fusermount3, mount.fuse, or custom FUSE daemons. Inspect mount logs and /proc or endpoint telemetry for unusual FUSE mounts, especially by low-privileged users or in directories under /tmp, /var/tmp, home directories, or application-writable paths. Review access to /dev/fuse and correlate it with suspicious data staging, compression, or exfiltration activity. Kernel logs may help identify abnormal FUSE errors or mount activity but should not be expected to conclusively prove exploitation. If sensitive memory exposure is suspected, rotate credentials and tokens that may have been resident on affected systems during the exposure window.

What your security team should do

• Prioritize patching multi-user Linux systems, developer workstations, container hosts, shared compute nodes, and systems where untrusted users can create FUSE mounts.
• Update to a vendor-fixed kernel and reboot; verify the active running kernel after maintenance.
• Enable init_on_alloc=1 or CONFIG_INIT_ON_ALLOC_DEFAULT_ON on higher-risk systems if performance testing is acceptable.
• Restrict or disable unprivileged FUSE mounts where business workflows do not require them.
• Inventory systems with /dev/fuse available and review which users or services can run FUSE daemons.
• Monitor for unusual creation of FUSE mounts, unexpected fusermount/fusermount3 usage, or FUSE activity by low-privileged accounts.
• Treat this as lower urgency than actively exploited remote vulnerabilities because it is not in CISA KEV, has no known exploit maturity, and has a low EPSS score, but do not defer indefinitely on shared or multi-tenant Linux systems.