CVE-2026-90400 in Linux
Sumário
de VulDB • 18/09/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
md: verificar alterações de spares antes de iniciar a sincronização
remove_spares() e remove_and_add_spares() modificam a configuração rdev da matriz (array). Essas operações só são seguras após a suspensão da matriz.
md_start_sync() verifica se há necessidade de alterações na configuração dos spares antes de adquirir reconfig_mutex. No entanto, o estado do rdev pode mudar antes que o mutex seja adquirido, fazendo com que a verificação inicial fique desatualizada (stale). Nesse caso, md_choose_sync_action() pode remover ou substituir os rdevs enquanto o I/O normal ainda está acessando-os.
A condição de corrida (race condition) pode ocorrer da seguinte forma:
raid10d Worker Normal IO ____________ _______________________ ______________________
raid10_write_request() wait_blocked_dev() set Blocked set Faulty Skip Faulty rdev rrdev->nr_pending++ .repl_bio = bio removeable_rdev = false . array not suspended . lock mddev goto err_handle lock mddev (wait) . update sb . clear Blocked . . unlock mddev . lock mddev (acquires) remove_spares() removeable_rdev = true
raid10_remove_disk() rdev = replacement replacement = NULL rdev_dec_pending(NULL) unlock mddev (NULL)->nr_pending--
Neste caso, rdev_dec_pending() é chamada com um ponteiro NULL, resultando em uma desreferência de ponteiro nulo ao tentar decrementar nr_pending.
Corrigir isso suspendendo a matriz quando alterações na configuração dos spares forem necessárias, incluindo para matrizes que não são read-write (leitura e gravação), e verificando novamente após adquirir reconfig_mutex. Se a matriz ainda não estava suspensa e uma alteração é agora necessária, liberar o mutex, suspender a matriz e reacquirir o mutex antes de continuar.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.