High [CVE-2026-53388] re-lock request before replacing page cache folio

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().

A flaw was found in the Linux kernel's Filesystem in Userspace (FUSE) component. The `fuse_try_move_folio()` function, responsible for managing page cache folios, fails to re-lock a request after initially unlocking it on a successful path.

This oversight allows another function, `fuse_chan_abort()`, to prematurely free critical input/output arguments (`fuse_io_args`). Consequently, subsequent operations attempting to access these freed arguments can lead to a use-after-free vulnerability, potentially allowing an attacker to cause a system crash or execute arbitrary code.