CVE-2026-53388 in Linux
Summary
by MITRE • 07/19/2026
In the Linux kernel, the following vulnerability has been resolved:
fuse: re-lock request before replacing page cache folio
fuse_try_move_folio() unlocks the request on entry but does not re-lock it on the success path. This means fuse_chan_abort() can end the request and free the fuse_io_args (eg fuse_readpages_end()) while the subsequent copy chain logic after fuse_try_move_folio() accesses the fuse_io_args, leading to use-after-free issues.
Fix this by calling lock_request() before replace_page_cache_folio(). This ensures the request is locked on the success path which will prevent the fuse_io_args from being freed while the later copying logic runs, and also ensures that the ap->folios[i]->mapping is never null
since ap->folios[i] will always point to the newfolio after
replace_page_cache_folio().
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 07/19/2026
The vulnerability described represents a critical use-after-free condition in the Linux kernel's FUSE (Filesystem in Userspace) subsystem that arises from improper locking semantics during page cache operations. This flaw exists within the fuse_try_move_folio() function where the request lock is released upon function entry but fails to be reacquired on the successful execution path. The fundamental issue stems from a race condition where concurrent operations can terminate and free memory structures while other code paths continue to reference them, creating a classic use-after-free scenario that can lead to system instability or potential privilege escalation.
The technical implementation flaw occurs when fuse_try_move_folio() unlocks a request but does not re-establish the lock before proceeding with page cache replacement operations. This sequence allows the fuse_chan_abort() function to terminate and free the fuse_io_args structure while subsequent copy chain logic continues to access these freed resources. The vulnerability specifically targets the interaction between kernel memory management and FUSE filesystem operations, where the replace_page_cache_folio() function is called without proper request locking, creating a window where the fuse_io_args structure becomes invalid while still being referenced by later code paths.
From an operational perspective, this vulnerability presents significant security implications as it could enable attackers to exploit the use-after-free condition for privilege escalation or system compromise. The impact extends beyond simple memory corruption since FUSE operates at the kernel level and handles filesystem operations that are critical to system stability. Attackers could potentially leverage this flaw to execute arbitrary code in kernel space, particularly when malicious data is processed through FUSE filesystems during read operations that trigger page cache replacement logic.
The fix implemented addresses the core issue by ensuring proper locking semantics through explicit lock_request() calls before replace_page_cache_folio() execution. This approach aligns with established security practices for concurrent access control and memory management in kernel space. The solution prevents the race condition by guaranteeing that the request remains locked throughout the critical section, thereby protecting the fuse_io_args structure from premature deallocation. Additionally, the fix ensures that ap->folios[i]->mapping will never be null since the newfolio always replaces the old one after replace_page_cache_folio() executes, maintaining proper data structure integrity.
This vulnerability demonstrates characteristics consistent with CWE-416 (Use After Free) and CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization), while potentially mapping to ATT&CK techniques involving privilege escalation through kernel vulnerabilities. The remediation approach follows established kernel security patterns for managing concurrent access to shared resources, particularly in filesystem implementations where memory management and locking must be carefully coordinated to prevent race conditions that could compromise system integrity. The fix represents a defensive programming solution that ensures proper synchronization between different kernel subsystems operating on the same data structures, aligning with broader security principles for kernel space memory management and resource protection.