A working, public proof-of-concept and full local-root exploit have appeared in early July for CVE-2026-31694, an out-of-bounds write in the Linux kernel’s FUSE (Filesystem in Userspace) directory-reading code. A malicious FUSE server can overflow a page-cache page and, by grooming that overflow onto the page-cache copy of /etc/passwd, hand an unprivileged local user a root shell. The underlying CVE was published in late June; the reason it matters now is that a reliable exploit is public. FUSE access is common in containers and unprivileged user namespaces, which makes this primarily a server and container-host risk.

What the Vulnerability Is

The flaw is a missing bounds check in fs/fuse/readdir.c, specifically in fuse_add_dirent_to_cache(). The function computes the size of a serialized directory entry from a server-controlled namelen field but does not verify that the resulting record fits inside a single page-cache page before copying it.

A malicious FUSE server can return a directory entry with namelen=4095, producing a serialized record of 4120 bytes. On systems with 4 KiB pages, the memcpy() then overflows the cache page by 24 bytes into the following kernel page — a classic out-of-bounds write into adjacent kernel memory.

The published exploit turns this write primitive into privilege escalation by grooming the 24-byte overflow so it lands on the page-cache copy of /etc/passwd, corrupting it in a way that yields an unprivileged local root. The flaw was reported by the AI-driven research firm Bynario; the public PoC repository includes both a "marker" PoC that demonstrates the write and a complete local privilege-escalation exploit, alongside a detailed technical writeup.

The bug affects Linux 6.15 and later and was fixed upstream by commit 51a8de6c50bf9 ("fuse: reject oversized dirents in page cache").

Why It Matters

  • Unprivileged local user to root. Any account that can trigger the vulnerable FUSE path can escalate to full control of the host.
  • A reliable exploit is now public. The write primitive plus a /etc/passwd page-cache LPE are published on GitHub with a writeup — attackers no longer have to develop it themselves.
  • Container and multi-tenant blast radius. FUSE mounts and user namespaces are routinely available inside containers and to unprivileged users, so shared hosting, Kubernetes nodes, and CI runners are the natural targets.
  • Targets a trusted on-disk file. Corrupting the cached /etc/passwd is a direct, well-understood path to authentication bypass and root.

Am I Affected?

You are likely affected if all of the following are true:

  • Your host runs a Linux kernel based on 6.15 or newer without the fix (upstream commit 51a8de6c50bf9 or a distribution backport).
  • Unprivileged users, tenants, or workloads can mount or attach a FUSE filesystem — for example via unprivileged user namespaces, allow_other/user_allow_other configurations, container runtimes that expose /dev/fuse, or desktop auto-mount helpers.

You are at lower risk if unprivileged FUSE mounts and user namespaces are disabled, or if only fully trusted code runs on the host. Confirm your kernel version with uname -r, and check whether unprivileged user namespaces are enabled with sysctl kernel.unprivileged_userns_clone (Debian/Ubuntu) or sysctl user.max_user_namespaces.

What to Do About It: Step-by-Step

Step 1: Check your kernel version

uname -r

If it is 6.15 or newer, assume exposure until patched.

Step 2: Patch first — update the kernel

Install the distribution kernel update that carries the FUSE fix:

# Debian / Ubuntu
sudo apt update && sudo apt full-upgrade

# RHEL / Rocky / AlmaLinux
sudo dnf update kernel

# openSUSE / SLES
sudo zypper patch

Confirm the vendor advisory references CVE-2026-31694 before assuming you are covered.

Step 3: Reboot into the patched kernel

Reboot (or apply live-patching if your vendor supports it for this CVE):

sudo reboot
uname -r   # verify the new version

Step 4: Mitigate while you wait for a backport — restrict unprivileged FUSE and user namespaces

These reduce or remove the attack path:

# Disable unprivileged user namespaces (Debian/Ubuntu)
sudo sysctl -w kernel.unprivileged_userns_clone=0

# Or cap user namespaces broadly
sudo sysctl -w user.max_user_namespaces=0

Make persistent by adding the setting to /etc/sysctl.d/. Test first — some container runtimes and sandboxed apps rely on user namespaces.

Step 5: Lock down FUSE mount options

Ensure user_allow_other is not enabled in /etc/fuse.conf unless required, and avoid granting untrusted users access to /dev/fuse inside containers.

Step 6: Harden container hosts

Prefer runtimes/policies that do not expose /dev/fuse to untrusted workloads; apply seccomp/AppArmor profiles that restrict the mount and FUSE syscalls where feasible.

Step 7: Monitor

Watch for unexpected FUSE mounts by unprivileged users, anomalous edits or cache corruption around /etc/passwd, and unexplained privilege escalations.

Quick-Win Checklist

  • Ran uname -r and confirmed whether the kernel is 6.15+.
  • Applied the distribution kernel update and confirmed it references CVE-2026-31694.
  • Rebooted (or live-patched) and verified the new kernel version.
  • Restricted unprivileged user namespaces where they aren’t needed.
  • Verified user_allow_other is off in /etc/fuse.conf unless required.
  • Ensured untrusted containers cannot reach /dev/fuse.
  • Enabled monitoring for rogue FUSE mounts and privilege escalation.

Sources