fuse: re-lock request before replacing page cache folio
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 5.15.211, 6.1.177, 6.6.144, 6.12.95, 6.18.37, and 2 more
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: none
- Automatable: no
- Technical impact: total
Summary
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().
Timeline
- CVE published
- CISA SSVC assessment
Exploitation: none · Automatable: no · Technical impact: total
- Record last updated
Affected versions
- Linux Linux
From ce534fb052928ce556639d7ecf01cbf4e01321e1 · fixed in 7c18691e0cfda29672f79bafde8abdb7710674f6; From ce534fb052928ce556639d7ecf01cbf4e01321e1 · fixed in 5927b43a4f8d89e86930f524bf63e9c7e66f61b4; From ce534fb052928ce556639d7ecf01cbf4e01321e1 · fixed in 030fe3e9d8abdee303dd7e9e42f45082d382a407; From ce534fb052928ce556639d7ecf01cbf4e01321e1 · fixed in 46473ddccdc5065033e397d6e62c280dbcd3d9c2; From ce534fb052928ce556639d7ecf01cbf4e01321e1 · fixed in af2892249d982a1c036ca456cc135374e68b6677; From ce534fb052928ce556639d7ecf01cbf4e01321e1 · fixed in 0223f452532d9cd8a5e87c45de828fd93c99bd25; From ce534fb052928ce556639d7ecf01cbf4e01321e1 · fixed in e28db6ac4792d065ab32565fd9f0a2361c3d4666; From ce534fb052928ce556639d7ecf01cbf4e01321e1 · fixed in a078484921052d0badd827fcc2770b5cfc1d4120
- Linux Linux
2.6.35
- KernelLinux
From 2.6.35 · fixed in 5.15.211; From 5.16.0 · fixed in 6.1.177; From 6.2.0 · fixed in 6.6.144; From 6.7.0 · fixed in 6.12.95; From 6.13.0 · fixed in 6.18.37; From 6.19.0 · fixed in 7.0.14; From 7.1.0 · fixed in 7.1.2
References 8
git.kernel.org
- stable/c/7c18691e0cfda29672f79bafde8abdb7710674f6
- stable/c/5927b43a4f8d89e86930f524bf63e9c7e66f61b4
- stable/c/030fe3e9d8abdee303dd7e9e42f45082d382a407
- stable/c/46473ddccdc5065033e397d6e62c280dbcd3d9c2
- stable/c/af2892249d982a1c036ca456cc135374e68b6677
- stable/c/0223f452532d9cd8a5e87c45de828fd93c99bd25
- stable/c/e28db6ac4792d065ab32565fd9f0a2361c3d4666
- stable/c/a078484921052d0badd827fcc2770b5cfc1d4120