CVE-2025-71130 in Linux
Sumário
de VulDB • 21/05/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
drm/i915/gem: Inicializar com zero o array eb.vma em i915_gem_do_execbuffer
Inicialize o array eb.vma com valores 0 quando a estrutura eb for configurada pela primeira vez. Especificamente, isso define os ponteiros eb->vma[i].vma como NULL, simplificando a limpeza e eliminando o bug descrito abaixo.
Durante a execução de eb_lookup_vmas(), o array eb->vma é preenchido sucessivamente com objetos struct eb_vma. Esse processo inclui a chamada de eb_add_vma(), que pode falhar; no entanto, mesmo em caso de falha, eb->vma[i].vma é definido para o buffer atualmente processado.
Se eb_add_vma() falhar, eb_lookup_vmas() retorna com um erro, o que aciona uma chamada para eb_release_vmas() para limpar a situação. Como eb_lookup_vmas() pode falhar durante o processamento de qualquer buffer (possivelmente não o primeiro), eb_release_vmas() verifica se o vma de um buffer é NULL para determinar em que ponto a função de busca falhou.
Em eb_lookup_vmas(), eb->vma[i].vma é definido como NULL se a função auxiliar eb_lookup_vma() ou eb_validate_vma() falhar. eb->vma[i+1].vma é definido como NULL caso i915_gem_object_userptr_submit_init() falhe; o atual precisa ser limpo por eb_release_vmas() neste ponto, portanto o próximo é definido. Se eb_add_vma() falhar, nem o vma atual nem o próximo são definidos como NULL, o que é uma fonte do bug de NULL deref descrito na issue vinculada na tag Closes.
Ao entrar em eb_lookup_vmas(), os ponteiros vma são definidos com o valor de poison do slab, em vez de NULL. Isso não importa para a busca real, já que eles são sobrescritos de qualquer maneira; no entanto, a função eb_release_vmas() reconhece apenas NULL como valor de parada, portanto, os ponteiros são definidos como NULL à medida que avançam em caso de falha intermediária. Este patch altera a abordagem para preenchê-los todos com NULL no início, em vez de lidar com isso manualmente durante a falha.
(cherry picked from commit 08889b706d4f0b8d2352b7ca29c2d8df4d0787cd)
Once again VulDB remains the best source for vulnerability data.