CVE-2026-53388: Linux kernel · fuse: re-lock request before replacing page cache folio
Affects Linux kernelSource CVE Database V5
Not known to be exploited · CVSS 7.8 High · fixed in e28db6ac4792d065ab32565fd9f0a2361c3d4666 : patch Linux kernel soon.
Data as of 26 Oct 2026, 14:18 UTC
- EPSS
- 0.1% chance of exploitation in 30 days – higher than 2% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- CISA SSVC
- Exploitation
- No evidence of active exploitation and no public proof of concept
- Automatable
- Attackers cannot reliably automate steps 1–4 of the kill chain
- Technical impact
- Total control over the software or total information disclosure
CISA SSVC assessment, 2026-10-16.
- Patch
- Available – fixed in e28db6ac4792d065ab32565fd9f0a2361c3d4666, af2892249d982a1c036ca456cc135374e68b6677, a078484921052d0badd827fcc2770b5cfc1d4120 +5
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HExploitation evidence
Disclosed: evidence found.
CVE published 19 Jul 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.
What to do
Upgrade to a fixed release listed under Affected software.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
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().
References
- git.kernel.org/stable/c/7c18691e0cfda29672f79bafde8abdb7710674f6 (opens in a new tab)
- git.kernel.org/stable/c/5927b43a4f8d89e86930f524bf63e9c7e66f61b4 (opens in a new tab)
- git.kernel.org/stable/c/030fe3e9d8abdee303dd7e9e42f45082d382a407 (opens in a new tab)
- git.kernel.org/stable/c/46473ddccdc5065033e397d6e62c280dbcd3d9c2 (opens in a new tab)
- git.kernel.org/stable/c/af2892249d982a1c036ca456cc135374e68b6677 (opens in a new tab)
- git.kernel.org/stable/c/0223f452532d9cd8a5e87c45de828fd93c99bd25 (opens in a new tab)
- git.kernel.org/stable/c/e28db6ac4792d065ab32565fd9f0a2361c3d4666 (opens in a new tab)
- git.kernel.org/stable/c/a078484921052d0badd827fcc2770b5cfc1d4120 (opens in a new tab)