No kernel Linux, a seguinte vulnerabilidade foi resolvida: ublk: reinicie os campos dev_info do kernel no ublk_ctrl_add_dev() ublk_ctrl_add_dev() memcpy()s o espaço de usuário ublksrv_ctrl_dev_info no ub->dev_info e então corrija os campos que o driver possui, mas erra ->estate e ->ublksrv_pid. Um dispositivo adicionado com ->state = UBLK_S_DEV_LIVE passa pelo teste "->state!= UBLK_S_DEV_DEAD" que o ublk_stop_dev_unlocked() usa como proxy para "um disco está anexado", enquanto que ->ub_disk ainda está NULL, então DEL_DEV logo após oopses ADD_DEV em del_gendisk(). UBLK_S_DEV_QUIESCED mais UBLK_F_USER_RECOVERY morre um passo antes, no ublk_force_abort_dev(). Um ->estado envenenado também recebe START_USER_RECOVERY e o caminho de leitura/escrita do dispositivo característico para um dispositivo que nunca foi iniciado, e cunha START_DEV no -EEXIST. Um envenenado ->ublksrv_pid apenas faz com que GET_DEV_INFO reporte uma tarefa não relacionada como o servidor ublk. Reinicie ambos depois do memcpy(), como o ublk_detach_disk() faz. O espaço de usuário só lê de volta, por isso corrigindo- os silenciosamente não quebra nada. ADD_ DEV copiou ->estado insalvado desde que o ublk foi fundido, mas naquela época era inofensivo: o gendisk foi alocado durante o ADD_ DEV, e tanto o rasgamento como a verificação START_ DEV - EEXIST foram teclados para fora do disk_live() em vez de ->estado. Os oops tornaram- se alcançáveis uma vez que a alocação do disco foi movida para START_DEV e as verificações mudaram para ->estado.
O registro do banco de dados nacional de vulnerabilidade CVE- 2026 - 74472 foi publicado em 2026 - 08 - 15 T 13: 17: 51.953 Z e última modificação em 2026 - 08 - 19 T 17: 21: 04.490 Z. O seu estado gravado é Recebido.
O registro NVD inclui referências de suporte documentando a vulnerabilidade, tecnologia afetada ou informações de remediação.