Answer in brief
CVE-2026-53388 records a Unknown severity vulnerability in fuse: re-lock request before replacing page cache folio. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
Answer in brief
CVE-2026-53388 records a Unknown severity vulnerability in fuse: re-lock request before replacing page cache folio. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=ce534fb052928ce556639d7ecf01cbf4e01321e1 <7c18691e0cfda29672f79bafde8abdb7710674f6 || >=ce534fb052928ce556639d7ecf01cbf4e01321e1 <5927b43a4f8d89e86930f524bf63e9c7e66f61b4 || >=ce534fb052928ce556639d7ecf01cbf4e01321e1 <030fe3e9d8abdee303dd7e9e42f45082d382a407 || >=ce534fb052928ce556639d7ecf01cbf4e01321e1 <46473ddccdc5065033e397d6e62c280dbcd3d9c2 || >=ce534fb052928ce556639d7ecf01cbf4e01321e1 <af2892249d982a1c036ca456cc135374e68b6677 || >=ce534fb052928ce556639d7ecf01cbf4e01321e1 <0223f452532d9cd8a5e87c45de828fd93c99bd25 || >=ce534fb052928ce556639d7ecf01cbf4e01321e1 <e28db6ac4792d065ab32565fd9f0a2361c3d4666 || >=ce534fb052928ce556639d7ecf01cbf4e01321e1 <a078484921052d0badd827fcc2770b5cfc1d4120 | 7c18691e0cfda29672f79bafde8abdb7710674f6, 5927b43a4f8d89e86930f524bf63e9c7e66f61b4, 030fe3e9d8abdee303dd7e9e42f45082d382a407, 46473ddccdc5065033e397d6e62c280dbcd3d9c2, af2892249d982a1c036ca456cc135374e68b6677, 0223f452532d9cd8a5e87c45de828fd93c99bd25, e28db6ac4792d065ab32565fd9f0a2361c3d4666, a078484921052d0badd827fcc2770b5cfc1d4120 |
| Linux/Linuxgeneric | 2.6.35 | Not reported |
Published upstream
Jul 19, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 5, 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().
Quoted source text, attributed separately from HOL analysis.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=ce534fb052928ce556639d7ecf01cbf4e01321e1 <7c18691e0cfda29672f79bafde8abdb7710674f6 || >=ce534fb052928ce556639d7ecf01cbf4e01321e1 <5927b43a4f8d89e86930f524bf63e9c7e66f61b4 || >=ce534fb052928ce556639d7ecf01cbf4e01321e1 <030fe3e9d8abdee303dd7e9e42f45082d382a407 || >=ce534fb052928ce556639d7ecf01cbf4e01321e1 <46473ddccdc5065033e397d6e62c280dbcd3d9c2 || >=ce534fb052928ce556639d7ecf01cbf4e01321e1 <af2892249d982a1c036ca456cc135374e68b6677 || >=ce534fb052928ce556639d7ecf01cbf4e01321e1 <0223f452532d9cd8a5e87c45de828fd93c99bd25 || >=ce534fb052928ce556639d7ecf01cbf4e01321e1 <e28db6ac4792d065ab32565fd9f0a2361c3d4666 || >=ce534fb052928ce556639d7ecf01cbf4e01321e1 <a078484921052d0badd827fcc2770b5cfc1d4120 | 7c18691e0cfda29672f79bafde8abdb7710674f6, 5927b43a4f8d89e86930f524bf63e9c7e66f61b4, 030fe3e9d8abdee303dd7e9e42f45082d382a407, 46473ddccdc5065033e397d6e62c280dbcd3d9c2, af2892249d982a1c036ca456cc135374e68b6677, 0223f452532d9cd8a5e87c45de828fd93c99bd25, e28db6ac4792d065ab32565fd9f0a2361c3d4666, a078484921052d0badd827fcc2770b5cfc1d4120 |
| Linux/Linuxgeneric | 2.6.35 | Not reported |
Published upstream
Jul 19, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 5, 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().
Quoted source text, attributed separately from HOL analysis.