CVE-2024-35872

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/secretmem: fix GUP-fast succeeding on secretmem folios<br /> <br /> folio_is_secretmem() currently relies on secretmem folios being LRU<br /> folios, to save some cycles.<br /> <br /> However, folios might reside in a folio batch without the LRU flag set, or<br /> temporarily have their LRU flag cleared. Consequently, the LRU flag is<br /> unreliable for this purpose.<br /> <br /> In particular, this is the case when secretmem_fault() allocates a fresh<br /> page and calls filemap_add_folio()-&gt;folio_add_lru(). The folio might be<br /> added to the per-cpu folio batch and won&amp;#39;t get the LRU flag set until the<br /> batch was drained using e.g., lru_add_drain().<br /> <br /> Consequently, folio_is_secretmem() might not detect secretmem folios and<br /> GUP-fast can succeed in grabbing a secretmem folio, crashing the kernel<br /> when we would later try reading/writing to the folio, because the folio<br /> has been unmapped from the directmap.<br /> <br /> Fix it by removing that unreliable check.