Cloudanix VulnDB

CVE-2026-80855

None

CVSS

—

EPSS

0.2%

Published

Sep 4, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A coding mistake in Linux file handling can cause parts of the system to freeze when certain storage features are used together.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Other
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

A read-write semaphore acquired via filemap_invalidate_lock for DAX truncate handling inside fuse_open is never released when fuse_dax_break_layouts returns -ERESTARTSYS after a signal interrupts dax_break_layout wait_page_idle, leaving the rwsem held and blocking all subsequent page faults or truncates on the same inode.

Why it matters to the business

Workloads using FUSE with DAX can experience indefinite stalls on file access after certain truncated opens are interrupted, reducing system availability and requiring reboots to recover affected files.

How an attack unfolds

An attacker with local access to a FUSE DAX mount issues an open with O_TRUNC, forces a signal to interrupt the layout-break wait inside fuse_dax_break_layouts, triggers the goto that skips the unlock, then performs any fault or truncate on the same file to block on the leaked lock.

How to fix it

Upgrade the Linux kernel to a version containing the upstream fix that moves filemap_invalidate_unlock below the renamed out_unlock label so every error path releases the lock.

How to confirm the fix worked

Inspect fuse_open in fs/fuse/file.c to confirm filemap_invalidate_unlock executes after the out_unlock label and that dax_truncate error paths no longer bypass the unlock.

Typical attack path

  1. Mount FUSE filesystem with DAX enabled
  2. Open target file with O_RDWR|O_TRUNC while DAX pages are busy
  3. Deliver signal to interrupt TASK_INTERRUPTIBLE wait in dax_break_layout
  4. Observe lock leak on error path
  5. Issue subsequent page fault or truncate to hang on stale rwsem

How to detect it

Search kernel logs and process listings for tasks blocked on inode rwsem or fuse_wait_dax_page after O_TRUNC opens; correlate with FUSE DAX mounts and recent signals delivered to fuse processes.

What your security team should do

  • Prioritize kernel updates for systems using FUSE DAX
  • Audit FUSE mount options and disable DAX where not required
  • Add monitoring for processes stuck in D-state on FUSE inodes

The record

In the Linux kernel, the following vulnerability has been resolved: fuse: fix invalidate lock leak on open O_TRUNC DAX failure fuse_open() takes filemap_invalidate_lock() for a DAX truncate (dax_truncate = true) and releases it before the out_inode_unlock label. But when fuse_dax_break_layouts() fails, the goto out_inode_unlock skips the unlock and leaks the rwsem, so any later fault or truncate on the file stalls on the stale lock. fuse_dax_break_layouts() can fail with -ERESTARTSYS when a signal interrupts the wait for busy DAX pages to drain: open("file", O_RDWR | O_TRUNC) └─ fuse_open() ├─ filemap_invalidate_lock() # dax_truncate └─ fuse_dax_break_layouts() └─ dax_break_layout() └─ wait_page_idle() # TASK_INTERRUPTIBLE └─ fuse_wait_dax_page() # unlock, schedule, re-lock └─ signal → -ERESTARTSYS goto out_inode_unlock # <- lock leaked Fix this by moving filemap_invalidate_unlock() below the label so that all error paths release the lock, and rename the label to out_unlock as it now covers more than just the inode lock.

Affected packages

Ecosystem Package Introduced Fixed