<Vulnerability name="CVE-2026-98223">
    <DocumentDistribution xml:lang="en">Copyright © 2012 Red Hat, Inc. All rights reserved.</DocumentDistribution>
    <ThreatSeverity>Low</ThreatSeverity>
    <PublicDate>2026-10-06T00:00:00</PublicDate>
    <Bugzilla id="2546455" url="https://bugzilla.redhat.com/show_bug.cgi?id=2546455" xml:lang="en:us">
kernel: mm: filemap: retain mapped dropbehind folios
    </Bugzilla>
    <CVSS3 status="draft">
        <CVSS3BaseScore>5.5</CVSS3BaseScore>
        <CVSS3ScoringVector>CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</CVSS3ScoringVector>
    </CVSS3>
    <CWE>CWE-821</CWE>
    <Details xml:lang="en:us" source="Mitre">
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.
    </Details>
    <Details xml:lang="en:us" source="Red Hat">
A flaw was found in the Linux kernel's memory management component. When dropbehind memory pages are mapped during read-ahead fault operations, the kernel can mistakenly attempt to execute a sleepable operation while running in an atomic, non-preemptible context upon writeback completion. A local user could exploit this flaw to cause a kernel crash, resulting in a denial of service (DoS).
    </Details>
    <Statement xml:lang="en:us">
A low impact flaw was found in the Linux kernel's memory management (mm/filemap) dropbehind handling. When fault-around maps read-ahead dropbehind folios without going through the normal page-cache lookup that clears dropbehind, the writeback completion path (folio_end_dropbehind()) can run in a non-preemptible atomic context and call unmap_mapping_folio(), which takes i_mmap_rwsem and may sleep. A local user could trigger this sleeping-in-atomic condition to cause a kernel warning or crash, resulting in a denial of service. There is no impact to confidentiality or integrity.

This issue affects Red Hat Enterprise Linux 10.3 and 10.4, and Red Hat In-Vehicle OS 2 (kernel and kernel-ivos-qualcomm components). Earlier Red Hat Enterprise Linux versions and streams (including RHEL 6, 7, 8, 9, and RHEL 10.0.z/10.2.z) and the OpenShift Container Platform RHEL CoreOS images are not affected because the vulnerable code is not present in those kernels. Fixes for the affected streams are deferred to a future update; the residual risk is limited to local denial of service. Although the CVSS:3.1 base score is 5.5 (Moderate), Red Hat rates the overall impact of this flaw as low because the demonstrated effect is a sleeping-in-atomic kernel warning with availability-only impact, and triggering it requires a local user with precise timing between fault-around mapping and writeback completion.
    </Statement>
    <Mitigation xml:lang="en:us">
Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base, or stability.
    </Mitigation>
    <PackageState cpe="cpe:/o:redhat:enterprise_linux:10">
        <ProductName>Red Hat Enterprise Linux 10</ProductName>
        <FixState>Fix deferred</FixState>
        <PackageName>kernel</PackageName>
    </PackageState>
    <PackageState cpe="cpe:/o:redhat:enterprise_linux:6">
        <ProductName>Red Hat Enterprise Linux 6</ProductName>
        <FixState>Out of support scope</FixState>
        <PackageName>kernel</PackageName>
    </PackageState>
    <PackageState cpe="cpe:/o:redhat:enterprise_linux:7">
        <ProductName>Red Hat Enterprise Linux 7</ProductName>
        <FixState>Not affected</FixState>
        <PackageName>kernel</PackageName>
    </PackageState>
    <PackageState cpe="cpe:/o:redhat:enterprise_linux:7">
        <ProductName>Red Hat Enterprise Linux 7</ProductName>
        <FixState>Not affected</FixState>
        <PackageName>kernel-rt</PackageName>
    </PackageState>
    <PackageState cpe="cpe:/o:redhat:enterprise_linux:8">
        <ProductName>Red Hat Enterprise Linux 8</ProductName>
        <FixState>Not affected</FixState>
        <PackageName>kernel</PackageName>
    </PackageState>
    <PackageState cpe="cpe:/o:redhat:enterprise_linux:8">
        <ProductName>Red Hat Enterprise Linux 8</ProductName>
        <FixState>Not affected</FixState>
        <PackageName>kernel-rt</PackageName>
    </PackageState>
    <PackageState cpe="cpe:/o:redhat:enterprise_linux:9">
        <ProductName>Red Hat Enterprise Linux 9</ProductName>
        <FixState>Not affected</FixState>
        <PackageName>kernel</PackageName>
    </PackageState>
    <PackageState cpe="cpe:/o:redhat:enterprise_linux:9">
        <ProductName>Red Hat Enterprise Linux 9</ProductName>
        <FixState>Not affected</FixState>
        <PackageName>kernel-rt</PackageName>
    </PackageState>
    <PackageState cpe="cpe:/a:redhat:openshift:4">
        <ProductName>Red Hat OpenShift Container Platform 4</ProductName>
        <FixState>Not affected</FixState>
        <PackageName>openshift/ose-rhel-coreos-8</PackageName>
    </PackageState>
    <PackageState cpe="cpe:/a:redhat:openshift:4">
        <ProductName>Red Hat OpenShift Container Platform 4</ProductName>
        <FixState>Not affected</FixState>
        <PackageName>openshift/ose-rhel-coreos-9</PackageName>
    </PackageState>
    <References xml:lang="en:us">
https://www.cve.org/CVERecord?id=CVE-2026-98223
https://nvd.nist.gov/vuln/detail/CVE-2026-98223
https://git.kernel.org/pub/scm/linux/security/vulns.git/plain/cve/published/2026/CVE-2026-98223.mbox
    </References>
</Vulnerability>