CVE-2026-80856: fuse: fix invalidate lock leak on setattr writeback failure
In the Linux kernel, the following vulnerability has been resolved:
fuse: fix invalidate lock leak on setattr writeback failure
fusedosetattr() takes filemapinvalidatelock() for a DAX truncate (faultblocked = true) and releases it at the out:/error: labels. But when a writeback flush is also needed, a writeinodenow() 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 fusedosetattr() with both ATTRSIZE and ATTRMODE set:
truncate(2) └─ dotruncate() ├─ dentryneedsremoveprivs() # SISUID └─ notifychange() # KILLSUID -> ATTRMODE └─ fusesetattr() # no killpriv: │ # iavalid |= ATTRMODE └─ fusedosetattr() ├─ filemapinvalidatelock() # ISDAX && istruncate └─ writeinodenow() # iswb && ATTRMODE └─ 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 fusedaxbreaklayouts() failure path as well.
Affected Software
Event History
Frequently Asked Questions
Under what conditions can this issue cause a file operation to stall?
The affected path requires a FUSE file using DAX, a truncate-related setattr operation that takes the invalidate lock, and a writeback flush requirement. If write_inode_now() then fails, such as when the FUSE daemon returns -EIO, the invalidate lock can remain held and later faults or truncates on that file can stall.
Is a FUSE daemon error required to trigger the lock leak?
Yes. The described leak occurs when write_inode_now() fails after fuse_do_setattr() has taken the invalidate lock. The example failure is an -EIO error from the FUSE daemon during a truncate of a setuid file that also changes mode.
What operations may indicate that a system is already affected?
Later page faults or truncate operations on the affected file may block on the stale invalidate rwsem after the failed setattr/writeback path. The triggering operation may have involved a DAX FUSE file and a writeback failure.