CVE-2026-80855 Overview
CVE-2026-80855 is a Linux kernel vulnerability in the Filesystem in Userspace (FUSE) subsystem. The flaw is a lock leak in fuse_open() triggered when opening a file with O_TRUNC on a Direct Access (DAX) backed FUSE mount. When fuse_dax_break_layouts() returns -ERESTARTSYS after a signal interrupts the wait for busy DAX pages to drain, the code path jumps to out_inode_unlock and skips filemap_invalidate_unlock(). The filemap_invalidate_lock rwsem remains held, causing any subsequent fault or truncate on the file to stall indefinitely. The fix moves the unlock below the label so every error path releases the lock.
Critical Impact
A local user with access to a DAX-backed FUSE mount can trigger a persistent rwsem leak by opening a file with O_TRUNC and delivering a signal, resulting in a filesystem denial of service.
Affected Products
- Linux kernel FUSE subsystem with DAX support enabled
- Distributions shipping vulnerable stable kernel branches prior to the referenced patches
- Systems using virtiofs or other FUSE filesystems mounted with DAX
Discovery Timeline
- 2026-09-04 - CVE-2026-80855 published to the National Vulnerability Database
- 2026-09-04 - Last updated in NVD database
Technical Details for CVE-2026-80855
Vulnerability Analysis
The vulnerability is a kernel resource leak classified as a lock leak leading to denial of service. fuse_open() acquires filemap_invalidate_lock() when handling a DAX truncate path (dax_truncate = true) and normally releases it before reaching the out_inode_unlock label. When fuse_dax_break_layouts() fails, the goto out_inode_unlock bypasses the corresponding filemap_invalidate_unlock() call. The rwsem stays held after the syscall returns.
After the leak, any subsequent operation that acquires the same invalidate lock, such as a page fault or another truncate on the same inode, blocks forever waiting on the stale writer. Because the leak is per-inode and persists until reboot, repeated triggers can render the affected file or mount unusable.
Root Cause
The root cause is an unlock omission on an error path. The lock acquisition sits in the DAX-specific prologue of fuse_open(), while the release sits inline before the shared cleanup label. When the goto out_inode_unlock fires after fuse_dax_break_layouts() returns an error, it skips the inline release. The upstream fix relocates filemap_invalidate_unlock() below the label and renames the label to out_unlock so all error paths uniformly release the rwsem.
Attack Vector
The attack is local. A user with access to a DAX-enabled FUSE mount opens a target file with O_RDWR | O_TRUNC. The call chain reaches fuse_wait_dax_page(), which sleeps in TASK_INTERRUPTIBLE state. Delivering a signal (for example via kill or pthread_kill) causes wait_page_idle() to return -ERESTARTSYS, walking into the leaking goto. Repeating this pattern across inodes produces sustained filesystem hangs.
No verified public exploit code is available. The reproduction sequence is described in the upstream commit message and does not require special privileges beyond access to the mount.
Detection Methods for CVE-2026-80855
Indicators of Compromise
- Processes stuck in uninterruptible sleep (D state) inside filemap_invalidate_lock_shared or filemap_invalidate_lock on FUSE inodes.
- Repeated open() syscalls with O_TRUNC on DAX-backed FUSE mounts followed by signal delivery to the calling process.
- Kernel hung_task warnings referencing FUSE inode operations after the affected file has been truncated.
Detection Strategies
- Monitor /proc/<pid>/stack for tasks blocked in FUSE invalidate lock acquisition paths and correlate with the owning mount.
- Enable CONFIG_DETECT_HUNG_TASK and alert on INFO: task ... blocked for more than N seconds messages naming FUSE or virtiofs.
- Audit kernel package versions across the fleet to identify hosts running FUSE/DAX code prior to the fix commits 1b04d80, 1d3e701, 7288c27, 776e85f, a61524d, a927f18, dcf30a5, and e981474.
Monitoring Recommendations
- Ingest dmesg and journald kernel logs into a centralized analytics pipeline and alert on hung task and rwsem contention warnings.
- Track syscall telemetry for anomalous open(..., O_TRUNC) bursts targeting FUSE mount points, especially when paired with signal delivery.
- Baseline FUSE mount health metrics such as pending I/O counts and inode lock hold times to detect regressions early.
How to Mitigate CVE-2026-80855
Immediate Actions Required
- Apply the upstream stable kernel patches referenced in the kernel.org commit list and rebuild or update affected kernels.
- Inventory hosts using FUSE filesystems with DAX enabled, including virtiofs guests, and prioritize them for patching.
- Restrict untrusted local access to DAX-backed FUSE mounts until patched kernels are deployed.
Patch Information
The upstream fix moves filemap_invalidate_unlock() below the shared cleanup label in fuse_open() and renames the label to out_unlock. Backports are available across multiple stable branches. Reference commits: 1b04d80, 1d3e701, 7288c27, 776e85f, a61524d, a927f18, dcf30a5, and e981474.
Workarounds
- Mount affected FUSE filesystems without the DAX option where the workload permits, avoiding the vulnerable dax_truncate path.
- Constrain the set of local users authorized to open files on DAX-backed FUSE mounts using file system permissions and namespaces.
- Reboot affected hosts to clear any leaked filemap_invalidate_lock rwsem state prior to patching if hangs are already observed.
# Verify running kernel and check for the fix
uname -r
# Example: remount a virtiofs mount without DAX (workload permitting)
umount /mnt/virtiofs-share
mount -t virtiofs myshare /mnt/virtiofs-share # omit the 'dax' option
# Detect tasks blocked in FUSE invalidate lock paths
for p in $(ps -eo pid,stat | awk '$2 ~ /D/ {print $1}'); do
grep -l filemap_invalidate_lock /proc/$p/stack 2>/dev/null && echo "PID $p blocked"
done
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

