Cloudanix VulnDB

CVE-2026-80856

None

CVSS

—

EPSS

0.2%

Published

Sep 4, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in Linux file handling on certain virtual filesystems can cause the computer to freeze during routine file size or permission changes.

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

What it actually does

A lock acquired during FUSE setattr handling for DAX truncate operations is not released on write_inode_now failure, leaving an rwsem held and blocking subsequent fault or truncate operations on the same file.

Why it matters to the business

File operations on FUSE-mounted DAX filesystems may stall indefinitely after certain attribute update failures, leading to application hangs and degraded system responsiveness until reboot.

How an attack unfolds

An attacker with local access triggers a truncate on a setuid file that also requires mode attribute changes; the failure path in write_inode_now returns without releasing the invalidate lock, causing all later operations on that file to block on the held rwsem.

How to fix it

Update to a Linux kernel containing the fix for the invalidate lock leak in fuse_do_setattr; apply the patch that introduces an unlock label before error returns.

How to confirm the fix worked

Confirm the kernel source contains the added unlock label and error path handling in fuse_do_setattr; test by reproducing the truncate-plus-writeback-failure sequence and verifying no lock remains held.

Typical attack path

  1. Mount a FUSE filesystem with DAX enabled
  2. Create or access a setuid file
  3. Issue truncate(2) that also clears SUID bits
  4. Induce writeback failure inside fuse_do_setattr
  5. Observe subsequent file operations blocking on the leaked lock

How to detect it

Inspect kernel logs for repeated FUSE setattr errors followed by hung tasks waiting on inode rwsem; correlate with processes stuck in fuse_do_setattr or filemap_invalidate_lock paths.

What your security team should do

  • Prioritize kernel updates on systems using FUSE with DAX
  • Monitor for file operation stalls on FUSE mounts as an operational indicator
  • Review FUSE usage in container and virtualization workloads for exposure

The record

In the Linux kernel, the following vulnerability has been resolved: fuse: fix invalidate lock leak on setattr writeback failure fuse_do_setattr() takes filemap_invalidate_lock() for a DAX truncate (fault_blocked = true) and releases it at the out:/error: labels. But when a writeback flush is also needed, a write_inode_now() failure returns directly and leaks the lock, so any later fault or truncate on the file stalls on the stale rwsem. For example, truncate(2) on a setuid file reaches fuse_do_setattr() with both ATTR_SIZE and ATTR_MODE set: truncate(2) └─ do_truncate() ├─ dentry_needs_remove_privs() # S_ISUID └─ notify_change() # KILL_SUID -> ATTR_MODE └─ fuse_setattr() # no killpriv: │ # ia_valid |= ATTR_MODE └─ fuse_do_setattr() ├─ filemap_invalidate_lock() # IS_DAX && is_truncate └─ write_inode_now() # is_wb && ATTR_MODE └─ if (err) # e.g. daemon -> -EIO return err # <- lock leaked Fix this by adding an unlock label that releases the lock before returning the error, and use it for the fuse_dax_break_layouts() failure path as well.

Affected packages

Ecosystem Package Introduced Fixed