CVE-2026-80895 in LinuxИнформация

Сводка

по VulDB • 04.09.2026

В ядре Linux устранена следующая уязвимость:

mshv: Упорядочивание публикации массива VP (pt_vp_array) относительно пути проверки irqfd

Функция mshv_partition_ioctl_create_vp() инициализирует структуру VP (выделение памяти, mutex_init, init_waitqueue_head, отображение страниц), а затем публикует указатель в partition->pt_vp_array. Несколько путей прерываний (ISR) читают этот массив без блокировок: перехват ISR, два планировщика ISRs и mshv_try_assert_irq_fast() на быстром пути irqfd.

Из них только mshv_try_assert_irq_fast() структурно может создать состояние гонки с публикацией. Она выполняется из пробуждателя eventfd без удержания pt_mutex, и MSHV_IRQFD не требует, чтобы целевой lapic_apic_id (== vp_index) указывал на существующую VP в момент регистрации. Следовательно, пользователь может зарегистрировать irqfd, направленный на еще не созданную VP, а затем запустить mshv_try_assert_irq_fast() одновременно с MSHV_CREATE_VP для того же индекса. На архитектурах со слабым порядком выполнения читатель может наблюдать ненулевой указатель в pt_vp_array до того, как инициализирующие записи в структуру VP станут видимыми, что приводит к использованию частично инициализированных полей (например, vp_register_page).

Другие читатели ISR не могут достичь этой гонки: гипервизор не будет генерировать сообщения о перехвате или планировщике для VP, которой никогда не было сказано запуститься, а пользователь может вызвать только MSHV_RUN_VP на файловом дескрипторе VP, возвращенном MSHV_CREATE_VP, который по конструкции возвращается после публикации. Оставьте этих читателей как обычные загрузки (plain loads).

Используйте smp_store_release() в mshv_partition_ioctl_create_vp() для публикации указателя и сопоставьте его с smp_load_acquire() в mshv_try_assert_irq_fast(). На x86 они компилируются в простые обращения при TSO; на ARM64 они генерируют барьеры acquire/release из одной инструкции, что приемлемо на этом быстром пути.

Путь уничтожения (destroy_partition(), очищающий pt_vp_array[i] до NULL после kfree(vp)) имеет отдельную проблему упорядочивания и времени жизни, которая выходит за рамки данной задачи.

If you want to get best quality of vulnerability data, you may have to visit VulDB.

Ответственный

Linux

Резервировать

26.08.2026

Раскрытие

04.09.2026

Модерация

принято

Вход

VDB-399088

EPSS

0.00000

KEV

Нет

Деятельности

Очень низкий

Источники

Do you know our Splunk app?

Download it now for free!