mm: filemap: retain mapped dropbehind folios
- 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 6.18.54, 7.2.8
- 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
Summary
In the Linux kernel, the following vulnerability has been resolved: mm: filemap: retain mapped dropbehind folios Fault-around can map ready dropbehind folios without going through the normal page-cache lookup that clears dropbehind. A mapping represents a competing cached user, so retain the folio instead of forcibly unmapping it when writeback completes. For a mapped folio, folio_unmap_invalidate() can call unmap_mapping_folio(), which takes i_mmap_rwsem and may sleep. Retaining mapped folios avoids this path when folio_end_dropbehind() runs in non-preemptible task context. Tal was able to trigger a sleeping-in-atomic warning due to this [1]. Unmapped dropbehind folios continue through the existing invalidation path.
Timeline
- CVE published
- Record last updated
Affected versions
- Linux Linux
From fb7d3bc4149395c1ae99029c852eab6c28fc3c88 · fixed in 2897601dffe576fcd87a4259102f41f7fb0cbfc8; From fb7d3bc4149395c1ae99029c852eab6c28fc3c88 · fixed in 77c0fade37c80e8aa16ac048a9828249055e3f66; From fb7d3bc4149395c1ae99029c852eab6c28fc3c88 · fixed in 848d2ce2fce15fbdc083fbf9691bfa72911033c4
- Linux Linux
6.14
- KernelLinux
From 6.14.0 · fixed in 6.18.54; From 6.19.0 · fixed in 7.2.8