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
7.8 HIGH (v3.1, CNA)CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
from ce534fb052928ce556639d7ecf01cbf4e01321e1 before 7c18691e0cfda29672f79bafde8abdb7710674f6; from ce534fb052928ce556639d7ecf01cbf4e01321e1 before 5927b43a4f8d89e86930f524bf63e9c7e66f61b4; from ce534fb052928ce556639d7ecf01cbf4e01321e1 before 030fe3e9d8abdee303dd7e9e42f45082d382a407; from ce534fb052928ce556639d7ecf01cbf4e01321e1 before 46473ddccdc5065033e397d6e62c280dbcd3d9c2; from ce534fb052928ce556639d7ecf01cbf4e01321e1 before af2892249d982a1c036ca456cc135374e68b6677; from ce534fb052928ce556639d7ecf01cbf4e01321e1 before 0223f452532d9cd8a5e87c45de828fd93c99bd25; from ce534fb052928ce556639d7ecf01cbf4e01321e1 before e28db6ac4792d065ab32565fd9f0a2361c3d4666; from ce534fb052928ce556639d7ecf01cbf4e01321e1 before a078484921052d0badd827fcc2770b5cfc1d4120
from 2.6.35 before 5.15.211; from 5.16 before 6.1.177; from 6.2 before 6.6.144; from 6.7 before 6.12.95; from 6.13 before 6.18.37; from 6.19 before 7.0.14; from 7.1 before 7.1.2
The CVE record is authoritative. Products marked “from the name” were identified from the CNA's free-text names, not a CPE, and are matched less certainly. This product uses the NVD API but is not endorsed or certified by the NVD.
Printed from infosecsignals.com. Every record links back to the agency that published it.
Your cookie choices
We use essential cookies to run this site, and, only with your consent, an advertising cookie from Google to measure whether our ads lead to sign-ups and subscriptions. See our for details.