CVE-2026-90181 in Linux
Sumário
de VulDB • 18/09/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
ublk: evitar loop de retry no desmonte em caso de falha na alocação da xarray
__ublk_shmem_remove_ranges() remove intervalos correspondentes nas árvores maple em lotes, mas primeiro armazena cada intervalo em uma xarray temporária para que as páginas possam ser desvinculadas (unpinned) após a liberação do lock da árvore maple.
Essa xarray temporária é preenchida sob o lock da árvore maple com xa_store(..., GFP_ATOMIC). Se o armazenamento falhar antes de mas_erase(), o intervalo atual permanece na árvore e a função auxiliar retorna false. O loop externo ublk_shmem_remove_ranges() então tenta imediatamente novamente o mesmo intervalo. Enquanto a alocação atômica continuar falhando, o caminho de desmonte não avança (não há progresso).
O problema pode ser reproduzido com injeção de failslab em radix_tree_node após um buffer SHMEM_ZC já ter sido registrado:
# Configuração do Kernel: # CONFIG_BLK_DEV_UBLK=y # CONFIG_DEBUG_FS=y # CONFIG_FAULT_INJECTION=y # CONFIG_FAULT_INJECTION_DEBUG_FS=y # CONFIG_FAILSLAB=y
echo 10 > /proc/sys/vm/nr_hugepages mkdir -p /tmp/htlb mount -t hugetlbfs none /tmp/htlb fallocate -l 4M /tmp/htlb/ublk_buf
dev_id=$(kublk add -t null --shmem_zc \ --htlb /tmp/htlb/ublk_buf | awk -F '[ :]' '/dev id/ {print $3}')
echo 1 > /sys/kernel/slab/radix_tree_node/failslab echo Y > /sys/kernel/debug/failslab/cache-filter echo Y > /sys/kernel/debug/failslab/ignore-gfp-wait echo 1 > /sys/kernel/debug/failslab/interval echo -1 > /sys/kernel/debug/failslab/times echo 100 > /sys/kernel/debug/failslab/probability
kublk del -n "$dev_id"
No kernel sem a correção, o comando de exclusão ainda estava em execução após 3 segundos. Desativar o failslab fez com que ele retornasse. A pilha de injeção de falhas mostrou:
should_failslab kmem_cache_alloc_lru_noprof __xas_nomem __xa_store xa_store __ublk_shmem_remove_ranges ublk_cdev_rel ublk_ctrl_del_dev
Remova a alocação do loop de desmonte. Mantenha o limite de lote existente, mas colete pares {base_pfn, nr_pages} em um array fixo na pilha (stack). Assim que um intervalo correspondente for encontrado, ele será apagado da árvore maple antes da liberação do lock, para que cada varredura bem-sucedida avance sem depender de nenhuma alocação GFP_ATOMIC.
Com as mesmas configurações de failslab, o kernel corrigido concluiu "kublk del -n $dev_id" com sucesso em cerca de 45 ms.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.