CVE-2026-98223: mm: filemap: retain mapped dropbehind folios
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, foliounmapinvalidate() can call unmapmappingfolio(), which takes immaprwsem and may sleep. Retaining mapped folios avoids this path when folioenddropbehind() 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1
Event History
Frequently Asked Questions
What conditions are needed to trigger the warning?
The issue requires fault-around to map a ready dropbehind folio, followed by writeback completion. In that state, the mapped folio can enter an invalidation path that takes i_mmap_rwsem and may sleep while running in non-preemptible task context.
Are unmapped dropbehind folios affected by this behavior?
No. Unmapped dropbehind folios continue through the existing invalidation path; the fix specifically retains folios that are mapped.
What is the practical impact described for affected systems?
The reported impact is a sleeping-in-atomic warning. The provided information does not describe exploitation requirements, a security impact beyond that warning, or temporary mitigations.