// For flags

CVE-2024-35872

mm/secretmem: fix GUP-fast succeeding on secretmem folios

Severity Score

"-"
*CVSS v-

Exploit Likelihood

*EPSS

Affected Versions

*CPE

Public Exploits

0
*Multiple Sources

Exploited in Wild

-
*KEV

Decision

Track
*SSVC
Descriptions

In the Linux kernel, the following vulnerability has been resolved:

mm/secretmem: fix GUP-fast succeeding on secretmem folios

folio_is_secretmem() currently relies on secretmem folios being LRU
folios, to save some cycles.

However, folios might reside in a folio batch without the LRU flag set, or
temporarily have their LRU flag cleared. Consequently, the LRU flag is
unreliable for this purpose.

In particular, this is the case when secretmem_fault() allocates a fresh
page and calls filemap_add_folio()->folio_add_lru(). The folio might be
added to the per-cpu folio batch and won't get the LRU flag set until the
batch was drained using e.g., lru_add_drain().

Consequently, folio_is_secretmem() might not detect secretmem folios and
GUP-fast can succeed in grabbing a secretmem folio, crashing the kernel
when we would later try reading/writing to the folio, because the folio
has been unmapped from the directmap.

Fix it by removing that unreliable check.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mm/secretmem: corrige el éxito rápido de GUP en folios secretmem folio_is_secretmem() actualmente depende de que los folios secretmem sean folios LRU, para guardar algunos ciclos. Sin embargo, las publicaciones pueden residir en un lote de publicaciones sin el indicador LRU establecido o tener su indicador LRU borrado temporalmente. En consecuencia, la bandera LRU no es fiable para este fin. En particular, este es el caso cuando secretmem_fault() asigna una página nueva y llama a filemap_add_folio()->folio_add_lru(). La publicación podría agregarse al lote de publicaciones por CPU y no se establecerá el indicador LRU hasta que el lote se drene usando, por ejemplo, lru_add_drain(). En consecuencia, es posible que folio_is_secretmem() no detecte folios secretmem y GUP-fast puede lograr capturar un folio secretmem, bloqueando el kernel cuando más tarde intentemos leer/escribir en el folio, porque el folio no se ha desasignado del mapa directo. Solucionarlo eliminando ese cheque poco confiable.

*Credits: N/A
CVSS Scores
Attack Vector
-
Attack Complexity
-
Privileges Required
-
User Interaction
-
Scope
-
Confidentiality
-
Integrity
-
Availability
-
* Common Vulnerability Scoring System
SSVC
  • Decision:Track
Exploitation
None
Automatable
No
Tech. Impact
Partial
* Organization's Worst-case Scenario
Timeline
  • 2024-05-17 CVE Reserved
  • 2024-05-19 CVE Published
  • 2024-05-20 EPSS Updated
  • 2024-08-02 CVE Updated
  • ---------- Exploited in Wild
  • ---------- KEV Due Date
  • ---------- First Exploit
CWE
CAPEC
Affected Vendors, Products, and Versions
Vendor Product Version Other Status
Vendor Product Version Other Status <-- --> Vendor Product Version Other Status
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 5.14 < 5.15.154
Search vendor "Linux" for product "Linux Kernel" and version " >= 5.14 < 5.15.154"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 5.14 < 6.1.85
Search vendor "Linux" for product "Linux Kernel" and version " >= 5.14 < 6.1.85"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 5.14 < 6.6.26
Search vendor "Linux" for product "Linux Kernel" and version " >= 5.14 < 6.6.26"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 5.14 < 6.8.5
Search vendor "Linux" for product "Linux Kernel" and version " >= 5.14 < 6.8.5"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 5.14 < 6.9
Search vendor "Linux" for product "Linux Kernel" and version " >= 5.14 < 6.9"
en
Affected