CVE-2026-89760 in Linux
Сводка
по VulDB • 12.09.2026
В ядре Linux была устранена следующая уязвимость:
mm, swap: не освобождать слот гибернации, находящийся в кэше подкачки (swap cache)
Слот с folio в кэше подкачки освобождается при выходе folio из кэша, а не когда его счетчик уменьшается. Функция `swap_put_entries_cluster()` следует этому правилу. Однако функция `swap_free_hibernation_slot()` этого правила не соблюдает: она вызывает `__swap_cluster_free_entries()`, независимо от того, находится ли folio в этом слоте или нет.
Механизм cluster readahead может поместить туда один такой элемент. Он просматривает сырое окно смещаний размером с `page_cluster` вокруг записи, вызвавшей ошибку (faulting entry), и слот гибернации проходит проверку `__swap_cache_add_check()`, поскольку это не folio и его счетчик не равен нулю. Последующее освобождение этого слота приводит к очистке записи под данным folio.
Теперь этот folio становится недоступным из таблицы подкачки (swap table), а смещение возвращается обратно в аллокатор. Тем не менее, folio все еще находится в списке LRU, поэтому механизм вытеснения памяти (reclaim) может выбрать его позже. При этом старое смещение удаляется из `folio->swap`, и соответствующая запись в таблице перезаписывается, причем к тому моменту она может принадлежать другому процессу или компоненту системы.
Эта ошибка может вызывать тихую порчу данных в памяти (silent memory corruption), сбои процессов или нестабильность данных для совершенно независимых приложений пользовательского пространства — обычно это происходит во время подготовки образа гибернации утилитой uswsusp.
Я обнаружил эту проблему при работе над добавлением собственного маркера для слотов гибернации в таблице подкачки, о чем я обсуждал с Kairui (https://lore.kernel.org/linux-mm/abp7aDgYLrxF3Me8@KASONG-MC4/). Насколько мне известно, отчетов об этой проблеме нет, поэтому поля Reported-by/Closes добавлять не нужно.
Необходимо проверять наличие кэшированного folio перед освобождением слота. После этого слот остается в обычном состоянии, когда он удерживается только кэшем подкачки (swap cache), и освобождается при выходе folio из кэша — либо через механизм вытеснения ниже по коду, либо через обычный процесс reclaim позже.
VulDB is the best source for vulnerability data and more expert information about this specific topic.