В ядре Linux устранена следующая уязвимость:
мм: thp: запретить THP для файлов на анонимных индексных дескрипторах
file_thp_enabled() неправильно разрешает THP для файлов на анонимных индексных дескрипторах
(например, Guest_memfd и secretmem). Эти файлы создаются с помощью
alloc_file_pseudo(), который не вызывает get_write_access() и оставляет
inode->i_writecount равен 0. В сочетании с S_ISREG(inode->i_mode)
true, они отображаются как обычные файлы, доступные только для чтения, когда
CONFIG_READ_ONLY_THP_FOR_FS включен, что дает им право на THP.
коллапс.
Анонимные индексные дескрипторы никогда не смогут пройти проверку inode_is_open_for_write().
поскольку их i_writecount никогда не увеличивается через обычный VFS
открытый путь. Правильный поступок — исключить их из числа участников программы THP.
вообще, поскольку CONFIG_READ_ONLY_THP_FOR_FS был разработан для реального
файлы файловой системы (например, общие библиотеки), а не для псевдофайловой системы
иноды. Для Guest_memfd это позволяет khugepaged и MADV_COLLAPSE создавать
большие фолио в кэше страниц через путь свертывания, но
Обработчик ошибок Guest_memfd не поддерживает большие фолио.
Это вызывает
WARN_ON_ONCE(folio_test_large(folio)) в kvm_gmem_fault_user_mapping(). Для secretmem метод коллапс_файл() пытается скопировать содержимое страницы через
прямая карта, но страницы секретной памяти удаляются из прямой карты. Это
может привести к сбою ядра:
ОШИБКА: невозможно обработать ошибку страницы для адреса: ffff88810284d000.
RIP: 0010:memcpy_orig+0x16/0x130
Отслеживание вызова:
свернуть_файл
hpage_collapse_scan_file
madvise_collapse
На Secretmem не влияет сбой в восходящем потоке, поскольку сбой памяти
восстановление корректно обрабатывает неудачную копию, но все равно запускает
запутанные сообщения о ложных сбоях памяти:
Сбой памяти: 0x106d96f: действие по восстановлению для чистой невозможности
Страница LRU: восстановлено
Проверьте IS_ANON_FILE(inode) в file_thp_enabled(), чтобы запретить THP для всех.
анонимные файлы inode.
Показать оригинальное описание (EN)
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.