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

mm: thp: deny THP for files on anonymous inodes

file_thp_enabled() incorrectly allows THP for files on anonymous inodes
(e.g. guest_memfd and secretmem). These files are created via
alloc_file_pseudo(), which does not call get_write_access() and leaves
inode->i_writecount at 0. Combined with S_ISREG(inode->i_mode) being
true, they appear as read-only regular files when
CONFIG_READ_ONLY_THP_FOR_FS is enabled, making them eligible for THP
collapse.

Anonymous inodes can never pass the inode_is_open_for_write() check
since their i_writecount is never incremented through the normal VFS
open path. The right thing to do is to exclude them from THP eligibility
altogether, since CONFIG_READ_ONLY_THP_FOR_FS was designed for real
filesystem files (e.g. shared libraries), not for pseudo-filesystem
inodes.

For guest_memfd, this allows khugepaged and MADV_COLLAPSE to create
large folios in the page cache via the collapse path, but the
guest_memfd fault handler does not support large folios. This triggers
WARN_ON_ONCE(folio_test_large(folio)) in kvm_gmem_fault_user_mapping().

For secretmem, collapse_file() tries to copy page contents through the
direct map, but secretmem pages are removed from the direct map. This
can result in a kernel crash:

BUG: unable to handle page fault for address: ffff88810284d000
RIP: 0010:memcpy_orig+0x16/0x130
Call Trace:
collapse_file
hpage_collapse_scan_file
madvise_collapse

Secretmem is not affected by the crash on upstream as the memory failure
recovery handles the failed copy gracefully, but it still triggers
confusing false memory failure reports:

Memory failure: 0x106d96f: recovery action for clean unevictable
LRU page: Recovered

Check IS_ANON_FILE(inode) in file_thp_enabled() to deny THP for all
anonymous inode files.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:

mm: thp: denegar THP para archivos en inodos anónimos

file_thp_enabled() permite incorrectamente THP para archivos en inodos anónimos (por ejemplo, guest_memfd y secretmem). Estos archivos se crean a través de alloc_file_pseudo(), que no llama a get_write_access() y deja inode->i_writecount en 0. Combinado con que S_ISREG(inode->i_mode) sea verdadero, aparecen como archivos regulares de solo lectura cuando CONFIG_READ_ONLY_THP_FOR_FS está habilitado, haciéndolos elegibles para el colapso de THP.

Los inodos anónimos nunca pueden pasar la verificación inode_is_open_for_write() ya que su i_writecount nunca se incrementa a través de la ruta de apertura VFS normal. Lo correcto es excluirlos por completo de la elegibilidad para THP, ya que CONFIG_READ_ONLY_THP_FOR_FS fue diseñado para archivos de sistemas de archivos reales (por ejemplo, bibliotecas compartidas), no para inodos de pseudo-sistemas de archivos.

Para guest_memfd, esto permite a khugepaged y MADV_COLLAPSE crear folios grandes en la caché de páginas a través de la ruta de colapso, pero el gestor de fallos de guest_memfd no soporta folios grandes. Esto activa WARN_ON_ONCE(folio_test_large(folio)) en kvm_gmem_fault_user_mapping().

Para secretmem, collapse_file() intenta copiar el contenido de la página a través del mapa directo, pero las páginas de secretmem se eliminan del mapa directo. Esto puede resultar en un fallo del kernel:

BUG: unable to handle page fault for address: ffff88810284d000
RIP: 0010:memcpy_orig+0x16/0x130
Call Trace:
collapse_file
hpage_collapse_scan_file
madvise_collapse

Secretmem no se ve afectado por el fallo en upstream ya que la recuperación de fallos de memoria maneja la copia fallida con elegancia, pero aún así activa informes confusos de falsos fallos de memoria:

Memory failure: 0x106d96f: recovery action for clean unevictable
LRU page: Recovered

Verificar IS_ANON_FILE(inode) en file_thp_enabled() para denegar THP para todos los archivos de inodos anónimos.