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

Linux kernel 安全漏洞

mm/secretmem: 修复GUP-fast在secretmem页面上的成功

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.

Linux kernel是美国Linux基金会的开源操作系统Linux所使用的内核。 Linux kernel存在安全漏洞。攻击者利用该漏洞导致内核崩溃。

在Linux内核中，已解决了以下漏洞： mm/secretmem：修复GUP-fast在secretmem页面上成功的问题 目前，`folio_is_secretmem()`依赖于secretmem页面是最近最少使用（LRU）页面，以节省一些循环。 然而，页面可能会存在于没有设置LRU标志的页面批中，或者暂时将其LRU标志清除。 因此，LRU标志对于此目的不可靠。 特别是，在`secretmem_fault()`分配一个新的页面并调用`filemap_add_folio()->folio_add_lru()`时，会出现这种情况。页面可能被添加到每个CPU的页面批中，直到使用`lru_add_drain()`等方法清空批后，才不会设置LRU标志。 因此，`folio_is_secretmem()`可能无法检测到secretmem页面，GUP-fast可以在抓取secretmem页面时成功，导致内核在稍后尝试读写页面时崩溃，因为页面已经被从直接映射中卸载。 通过移除这个不可靠的检查来修复它。