In the Linux kernel, the following vulnerability has been resolved: fuse: re-lock request before replacing page cache folio fuse_try_move_folio()… (CVE-2026-53388)
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().
AI Analysis
Technical Summary
The vulnerability in the Linux kernel's FUSE module arises from fuse_try_move_folio() unlocking a request upon entry but not re-locking it on the success path. This flaw allows fuse_chan_abort() to end the request and free fuse_io_args while later code still accesses these freed resources, causing a use-after-free condition. The patch ensures that lock_request() is called before replace_page_cache_folio(), maintaining the request lock during the critical section and preventing the use-after-free scenario. Additionally, this fix guarantees that the page cache folio's mapping pointer is never null after replacement.
Potential Impact
The vulnerability can cause use-after-free conditions in the FUSE kernel module, potentially leading to kernel memory corruption or instability. However, no known exploits in the wild have been reported. The impact is limited to systems running the affected Linux kernel with FUSE enabled and vulnerable code paths executed.
Mitigation Recommendations
A fix for this vulnerability has been implemented by calling lock_request() before replace_page_cache_folio() in the Linux kernel FUSE code. Users should apply the official kernel updates or patches that include this fix. Since this is a kernel-level issue, updating to a patched kernel version is the recommended remediation. Patch status is not explicitly confirmed in the provided data; therefore, check the vendor or Linux kernel mailing list advisories for the latest patch information.
In the Linux kernel, the following vulnerability has been resolved: fuse: re-lock request before replacing page cache folio fuse_try_move_folio()… (CVE-2026-53388)
Description
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().
CVSS v3.1
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The vulnerability in the Linux kernel's FUSE module arises from fuse_try_move_folio() unlocking a request upon entry but not re-locking it on the success path. This flaw allows fuse_chan_abort() to end the request and free fuse_io_args while later code still accesses these freed resources, causing a use-after-free condition. The patch ensures that lock_request() is called before replace_page_cache_folio(), maintaining the request lock during the critical section and preventing the use-after-free scenario. Additionally, this fix guarantees that the page cache folio's mapping pointer is never null after replacement.
Potential Impact
The vulnerability can cause use-after-free conditions in the FUSE kernel module, potentially leading to kernel memory corruption or instability. However, no known exploits in the wild have been reported. The impact is limited to systems running the affected Linux kernel with FUSE enabled and vulnerable code paths executed.
Mitigation Recommendations
A fix for this vulnerability has been implemented by calling lock_request() before replace_page_cache_folio() in the Linux kernel FUSE code. Users should apply the official kernel updates or patches that include this fix. Since this is a kernel-level issue, updating to a patched kernel version is the recommended remediation. Patch status is not explicitly confirmed in the provided data; therefore, check the vendor or Linux kernel mailing list advisories for the latest patch information.
Technical Details
- Gcve Source
- db.gcve.eu
- Osv Id
- GHSA-45w6-5frg-3vfq
- Osv Schema Version
- 1.4.0
- Aliases
- ["CVE-2026-53388"]
- Ecosystems
- []
- Database Specific Severity
- null
- Cvss Version
- null
Threat ID: 6a5d27ad2a4a8d59891325b7
Added to database: 07/19/2026, 19:38:21 UTC
Last enriched: 07/19/2026, 20:24:38 UTC
Last updated: 07/20/2026, 19:41:22 UTC
Views: 16
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.