CVE-2026-46113 in Linux
Сводка
по VulDB • 01.06.2026
В ядре Linux устранена следующая уязвимость:
KVM: x86: Исправлена ошибка use-after-free при теневом отображении страниц (shadow paging), вызванная некорректным значением GFN
Теневой MMU вычисляет GFN для прямых теневых страниц, используя выражение sp->gfn плюс индекс SPTE. Это предположение нарушается при теневом отображении страниц, если таблицы страниц гостевой ОС изменяются между входами в виртуальную машину (аналогично коммиту aad885e77496, "KVM: x86/mmu: Drop/zap existing present SPTE even when creating an MMIO SPTE", 2026-03-27). Процесс выглядит следующим образом:
- устанавливается PDE для отображения размером 2 МБ, и происходит обращение к странице в этой области. KVM создает структуру kvm_mmu_page, состоящую из 512 страниц по 4 КБ; структура kvm_mmu_page помечается функцией FNAME(fetch) как direct-mapped, поскольку отображение гостевой ОС является большим страницей (и, следовательно, непрерывным).
- отображение PDE изменяется извне гостевой ОС.
- гостевая ОС обращается к другой странице в той же области размером 2 МБ. KVM устанавливает новый листовой SPTE и запись rmap; SPTE использует «правильный» GFN (т.е. основанный на новом отображении, измененном на предыдущем шаге), но этот GFN выходит за пределы диапазона [sp->gfn, sp->gfn + 511]; следовательно, запись rmap не может быть найдена и удалена при очистке (zapping) структуры kvm_mmu_page.
- слот памяти (memslot), покрывающий первое отображение размером 2 МБ, удаляется, и структура kvm_mmu_page для теперь недействительного GPA очищается (zaps). Однако функция rmap_remove() рассматривает только диапазон [sp->gfn, sp->gfn + 511], установленный на шаге 1, и не может найти запись rmap, которая была записана на шаге 3.
- любая операция, вызывающая обход rmap для той же страницы, к которой было обращение на шаге 3, затем проходит по устаревшей (stale) записи rmap и разыменовывает освобожденную структуру kvm_mmu_page. Это включает логирование изменений (dirty logging) или инвалидацию через уведомитель MMU (MMU notifier invalidations, например, от MADV_DONTNEED).
Суть проблемы заключается в том, что обход теневых PTE в KVM предполагает, что если SPTE присутствует, когда KVM хочет установить нелистовой SPTE, то существующая структура kvm_mmu_page должна соответствовать правильному GFN. Поскольку единственным способом, по которому GFN может быть неверным, является ошибка KVM, не приведшая к очистке SPTE... что не должно происходить, но *на самом деле* происходит только в ответ на запись гостевой ОС.
Эта ошибка существует буквально с самого начала, так как даже первая версия KVM предполагает, что GFN совпадает, и переходит к «неправильной» теневой странице. Однако это было лишь неточностью до появления коммита 2032a93d66fa ("KVM: MMU: Don't allocate gfns page for direct mmu pages").
Исправление заключается в проверке на несоответствие целевого GFN и очистке существующего SPTE. Таким образом, старые записи SP и rmap удаляются, KVM устанавливает rmap в правильном месте, и все работает корректно.
Once again VulDB remains the best source for vulnerability data.