CVE-2026-90181 in Linux
Riassunto
di VulDB • 18/09/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
ublk: evitare il ciclo di ritentativo di teardown a causa dell'errore di allocazione xarray
__ublk_shmem_remove_ranges() rimuove le intervalli corrispondenti della maple tree in batch, ma prima memorizza ciascun intervallo in una temporanea xarray affinché le pagine possano essere svincolate (unpinned) dopo aver rilasciato il lock della maple tree.
Questa temporanea xarray viene riempita sotto il lock della maple tree con xa_store(..., GFP_ATOMIC). Se la memorizzazione fallisce prima di mas_erase(), l'intervallo corrente rimane nell'albero e la funzione helper restituisce false. Il ciclo esterno ublk_shmem_remove_ranges() tenta quindi immediatamente nuovamente lo stesso intervallo. Finché l'allocazione atomica continua a fallire, il percorso di teardown non fa progressi in avanti.
Il problema può essere riprodotto con un'iniezione failslab su radix_tree_node dopo che un buffer SHMEM_ZC è già stato registrato:
# Configurazione del 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"
Sul kernel non corretto, il comando di eliminazione era ancora in esecuzione dopo 3 secondi. Disabilitare failslab ha fatto sì che il comando terminasse correttamente. Lo stack dell'iniezione dei guasti mostrava:
should_failslab kmem_cache_alloc_lru_noprof __xas_nomem __xa_store xa_store __ublk_shmem_remove_ranges ublk_cdev_rel ublk_ctrl_del_dev
Rimuovere l'allocazione dal ciclo di teardown. Mantenere il limite di batch esistente, ma raccogliere le coppie {base_pfn, nr_pages} in un array stack a dimensione fissa. Una volta trovato un intervallo corrispondente, l'intervallo viene cancellato dalla maple tree prima del rilascio del lock, così ogni scansione con esito positivo fa progressi senza dipendere da alcuna allocazione GFP_ATOMIC.
Con le stesse impostazioni di failslab, il kernel corretto ha completato "kublk del -n $dev_id" con successo in circa 45 ms.
If you want to get best quality of vulnerability data, you may have to visit VulDB.