Linux Kernel FUSE Flaw Could Let Local Attackers Gain Root Privileges

A reported Linux kernel vulnerability in the FUSE subsystem could allow a local attacker to corrupt cached executable data and gain root privileges on affected systems.

The issue, reported as CVE-2026-31694, affects the kernel code that adds directory entries returned by a userspace FUSE server to the page cache. A malicious server can allegedly supply an oversized directory entry that crosses a page boundary and overwrites data in an adjacent cache page.

Bynario researchers demonstrated how the memory corruption could target cached code from a setuid-root executable. When the modified program runs, the injected instructions can change the process identity to root and bypass its normal authentication checks.

The vulnerability affects cached FUSE directory entries

FUSE, short for Filesystem in Userspace, allows filesystem logic to run outside the kernel while communicating with the kernel through /dev/fuse. The Linux kernel FUSE documentation explains how the kernel forwards filesystem requests to a userspace process.

A FUSE server can return directory entries when an application reads a mounted directory. The kernel may place those results in the page cache so later directory reads do not need to request the same information again.

The reported flaw exists in fuse_add_dirent_to_cache(), which prepares and copies a returned directory entry into a cache page. The function calculates the entry size using a filename length controlled by the FUSE server.

Component	Role in the attack
Malicious FUSE server	Returns a directory entry containing an attacker-controlled filename length
fuse_add_dirent_to_cache()	Calculates and copies the serialized entry into the page cache
Page cache	Stores directory data and cached pages belonging to other files
Setuid executable	Runs with elevated privileges after its cached code has been modified

An oversized entry can cross a 4 KiB page boundary

According to the technical analysis, the vulnerable code checks whether an entry fits in the remaining space of the current page. If it does not, the code moves the write offset back to the start of a page.

However, the code reportedly failed to reject an individual directory entry that was larger than an entire memory page. On a system using 4 KiB pages, a malicious server could produce a serialized entry measuring 4,120 bytes.

The kernel would copy the record into a single 4,096-byte page. The remaining 24 bytes would then spill into the next physical page and overwrite data stored there.

• The attacker mounts or controls a malicious FUSE filesystem.
• The FUSE server returns an entry containing an oversized filename.
• The serialized entry becomes larger than one 4 KiB page.
• The kernel resets the cache offset and starts copying at the page boundary.
• The final bytes overwrite data in an adjacent page.

The fuse(4) manual page describes the request and response protocol used between the kernel and the userspace filesystem process. The vulnerability arises because the kernel must treat data returned through that interface as untrusted.

Attackers can target executable data in the page cache

The overflow becomes a privilege-escalation primitive when the attacker can influence which file occupies the adjacent cache page. Bynario’s reported demonstration placed cached data from a setuid-root executable next to the overflowing FUSE page.

Linux uses the page cache to keep recently accessed file content in memory. This can include executable code from programs such as /usr/bin/su.

By overwriting the beginning of cached executable code, an attacker can change what the processor runs without modifying the original file on disk. The corrupted page may remain active until the kernel removes or replaces it.

Stage	Attacker objective
Page preparation	Place a useful target file in the page cache
Memory placement	Position the target page next to the FUSE cache page
Overflow	Replace selected bytes in the cached executable
Execution	Run the modified setuid program
Privilege escalation	Execute attacker-controlled code with root privileges

A modified setuid program can produce a root shell

Setuid executables run with the effective identity of their owner rather than only the identity of the user launching them. Programs such as su commonly belong to root and use setuid permissions to perform privileged authentication and account changes.

The reported proof of concept replaced the beginning of a cached setuid executable with a small payload that called setuid(0) and setgid(0). These system calls set the process user and group identities to root when executed from a suitably privileged process.

After changing its identity, the modified program could continue running or start a command shell. This allows the attacker to bypass the program’s intended authentication path.

1. Load a root-owned setuid executable into the page cache.
2. Arrange the cache pages so the executable sits beside the FUSE entry page.
3. Trigger the oversized directory-entry copy.
4. Overwrite the executable’s cached instructions with a small payload.
5. Run the setuid program and execute the payload as root.

The original executable file may remain unchanged on disk. File-integrity checks that read only stored content may therefore miss the temporary modification unless they also inspect memory or detect the exploitation behavior.

The attack requires local FUSE access

The issue represents a local privilege-escalation vulnerability rather than a directly remote attack. An attacker first needs the ability to execute code as an unprivileged user and operate a FUSE filesystem.

On many Linux systems, ordinary users can mount approved FUSE filesystems through fusermount3. Access may also become available inside an unprivileged user namespace, depending on the distribution and its security settings.

The user_namespaces(7) documentation explains how user namespaces can grant a process capabilities within an isolated namespace without granting equivalent privileges in the initial namespace.

Requirement	Details
Local code execution	The attacker must already run commands as a local user or compromised service
FUSE availability	The system must allow the attacker to access or operate a FUSE filesystem
Vulnerable kernel	The running kernel must contain the affected caching logic
4 KiB pages	The reported overflow relies on the demonstrated entry size exceeding a 4 KiB page
Useful privileged target	The attacker needs an executable or another security-sensitive page to corrupt

Containers and shared development systems may face additional risk when they allow untrusted users to create user namespaces or access FUSE devices.

The reported exploit targets systems with 4 KiB pages

Bynario reported that the demonstrated overflow affects systems using 4 KiB memory pages. The crafted directory entry measured 4,120 bytes, leaving a 24-byte overwrite beyond the page boundary.

Architectures or configurations using larger page sizes would contain an entry of that size within one page. They would therefore not experience the exact overflow demonstrated by the researchers.

This does not necessarily prove that every larger-page configuration is safe from all variations. Administrators should rely on kernel and distribution advisories once maintainers publish confirmed affected versions and patches.

• x86-64 Linux systems commonly use 4 KiB pages.
• Some ARM64 systems use 16 KiB or 64 KiB pages.
• The demonstrated entry exceeds a 4 KiB page by 24 bytes.
• The exploit also depends on page-cache placement and local FUSE access.

The page size alone does not determine vulnerability status. Vendors may backport fixes, modify the affected code or disable relevant functionality in their distributed kernels.

Large readdir buffers may make exploitation possible

The reported issue affects the path used to cache results from FUSE readdir operations. Readdir requests return information about files and directories to applications enumerating filesystem contents.

Newer kernel configurations can use larger buffers for these results. Although the overall response buffer can hold the malicious entry, the individual cache page remains limited to the system page size.

The missing validation reportedly allowed the kernel to accept an entry that fit inside the larger response buffer but could not fit inside the single destination page.

The kernel FUSE guide notes that FUSE requests and responses pass through a defined userspace interface. Kernel code must validate response sizes before using data supplied by a filesystem daemon.

The fix rejects entries that exceed one page

The reported correction adds a size check before the kernel copies a directory entry into the cache. If the serialized record exceeds PAGE_SIZE, the caching operation rejects it instead of attempting the copy.

This prevents a single FUSE directory entry from crossing the cache-page boundary. The check addresses the underlying issue without requiring the kernel to trust filename lengths supplied by a userspace filesystem.

Administrators should install updated kernel packages from their Linux distribution once patches become available. They should then restart the system because replacing the kernel package alone does not update the kernel currently running in memory.

1. Check the kernel version running on each system.
2. Review security notices from the relevant Linux distribution.
3. Install a kernel package containing the FUSE validation fix.
4. Restart the system into the corrected kernel.
5. Confirm the active kernel version after rebooting.

Organizations should avoid relying only on upstream version numbers. Enterprise distributions often backport individual fixes without changing to the newest upstream kernel branch.

Administrators can temporarily restrict FUSE access

Systems that cannot receive a kernel update immediately can reduce exposure by limiting access to FUSE and unprivileged namespace features.

Removing the setuid bit from fusermount3 may stop ordinary users from creating certain FUSE mounts. However, this change can break desktop applications, encrypted filesystems, remote storage tools and development workflows.

Administrators can also restrict access to /dev/fuse or disable unprivileged user namespaces where operationally appropriate. The Linux user namespace manual provides technical background on namespace creation and capability handling.

• Restrict access to /dev/fuse to approved users and services.
• Disable unnecessary unprivileged user namespaces.
• Review whether fusermount3 requires setuid permissions.
• Limit FUSE use inside untrusted containers and build environments.
• Monitor unexpected FUSE mounts created by ordinary user accounts.

These measures reduce attack opportunities but may not provide complete protection. Installing a corrected kernel remains the preferred response.

Security teams should monitor for unusual FUSE activity

Endpoint monitoring can help identify attempted exploitation, although a successful page-cache corruption attack may not create an obvious file modification on disk.

Teams should look for unexpected FUSE mounts, access to /dev/fuse, unusual fusermount3 execution and repeated directory reads against newly created userspace filesystems.

The FUSE device interface documentation describes the messages exchanged through /dev/fuse. Security tools can use process and device-access telemetry to identify unfamiliar programs acting as filesystem servers.

• Unrecognized processes opening /dev/fuse
• New FUSE mounts created by service or web application accounts
• fusermount3 launched from unusual parent processes
• Setuid programs executed immediately after FUSE activity
• Kernel crashes or memory-corruption warnings involving FUSE
• Unexpected root shells created by previously unprivileged accounts

Security teams should preserve kernel logs, process telemetry and mount information when investigating suspicious activity. Restarting an affected system may remove corrupted cache pages and other volatile evidence.

Shared Linux systems face the greatest risk

The vulnerability poses the highest risk to systems where untrusted users can run code and create FUSE mounts. Examples include shared servers, university systems, continuous integration workers and multi-user development environments.

A remote attacker could also use the flaw after gaining limited access through another vulnerability, stolen credentials or a compromised application. The FUSE issue could then provide the second stage needed to obtain root privileges.

Administrators should prioritize systems that combine 4 KiB pages, local untrusted workloads, accessible FUSE functionality and root-owned setuid programs.

Environment	Risk factor
Shared development server	Several untrusted users can execute local code
CI runner	Build jobs may process code supplied by external contributors
Container host	Workloads may access namespaces or exposed FUSE devices
Desktop Linux system	Users often have access to fusermount3 for legitimate applications
Single-purpose server	Risk remains lower when local accounts and FUSE access are tightly restricted

Until maintainers publish definitive package information, organizations should review their exposure, follow distribution advisories and prepare to deploy updated kernels quickly.

FAQ