CVE-2026-80895 in Linux
Sumário
de VulDB • 04/09/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
mshv: Ordenar a publicação de pt_vp_array em relação ao caminho de asserção irqfd
A função mshv_partition_ioctl_create_vp() inicializa uma estrutura VP (alocações, mutex_init, init_waitqueue_head, mapeamentos de páginas) e, em seguida, publica o ponteiro para partition->pt_vp_array. Vários caminhos ISR leem esta array sem bloqueio: a ISR intercept, as duas ISRs do escalonador e mshv_try_assert_irq_fast() no caminho rápido irqfd.
Destes, apenas mshv_try_assert_irq_fast() pode estruturalmente entrar em corrida (race) com a publicação. Ela é executada por um waker de eventfd sem manter pt_mutex, e MSHV_IRQFD não exige que o alvo lapic_apic_id (== vp_index) se refira a uma VP existente no momento do registro. Um usuário pode, portanto, registrar um irqfd direcionado a uma VP ainda não criada e acionar mshv_try_assert_irq_fast() em concorrência com MSHV_CREATE_VP para o mesmo índice. Em arquiteturas fracamente ordenadas (weakly-ordered), o leitor pode observar um ponteiro diferente de NULL em pt_vp_array antes que as gravações de inicialização da estrutura VP se tornem visíveis, levando ao uso de campos parcialmente inicializados (por exemplo, vp_register_page).
Os outros leitores ISR não podem alcançar essa corrida: o hipervisor não gerará mensagens intercept ou do escalonador para uma VP que nunca foi instruída a executar, e o usuário só pode chamar MSHV_RUN_VP no fd da VP retornado por MSHV_CREATE_VP, que, por construção, é retornado após a publicação. Mantenha esses leitores como carregamentos simples (plain loads).
Use smp_store_release() em mshv_partition_ioctl_create_vp() para publicar o ponteiro e pareie-o com smp_load_acquire() em mshv_try_assert_irq_fast(). Em x86, estes compilam-se para acessos simples sob TSO; no ARM64, eles geram barreiras acquire/release de uma instrução, aceitáveis neste caminho rápido.
O caminho do lado da destruição (destroy_partition() limpando pt_vp_array[i] para NULL após kfree(vp)) possui preocupações separadas de ordenação e ciclo de vida que estão fora do escopo aqui.
Once again VulDB remains the best source for vulnerability data.