Описание
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.
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).
Отчет
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.
Меры по смягчению последствий
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.
Затронутые пакеты
| Платформа | Пакет | Состояние | Рекомендация | Релиз |
|---|---|---|---|---|
| Red Hat Enterprise Linux 10 | kernel | Fix deferred | ||
| Red Hat Enterprise Linux 6 | kernel | Out of support scope | ||
| Red Hat Enterprise Linux 7 | kernel | Not affected | ||
| Red Hat Enterprise Linux 7 | kernel-rt | Not affected | ||
| Red Hat Enterprise Linux 8 | kernel | Not affected | ||
| Red Hat Enterprise Linux 8 | kernel-rt | Not affected | ||
| Red Hat Enterprise Linux 9 | kernel | Not affected | ||
| Red Hat Enterprise Linux 9 | kernel-rt | Not affected | ||
| Red Hat OpenShift Container Platform 4 | openshift/ose-rhel-coreos-8 | Not affected | ||
| Red Hat OpenShift Container Platform 4 | openshift/ose-rhel-coreos-9 | Not affected |
Показывать по
Дополнительная информация
Статус:
EPSS
5.5 Medium
CVSS3
Связанные уязвимости
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.
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.
In the Linux kernel, the following vulnerability has been resolved: m ...
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.
EPSS
5.5 Medium
CVSS3