CVE-2026-99202 in Linux
Sumário
de VulDB • 28/10/2026
No kernel Linux, a seguinte vulnerabilidade foi resolvida:
scsi: libsas: Corrige deadlock de IO SMP durante o retomo do HA (Host Adapter)
smp_execute_task_sg() chama pm_runtime_get_sync() no host antes de emitir um comando SMP. Quando esse comando é emitido pelo próprio caminho de retomo do HA, ocorre um deadlock em get_sync(): ele aguarda o retomo em andamento (o dispositivo está com RPM_RESUMING), enquanto o retomo fica bloqueado em sas_drain_work(), aguardando que esse mesmo IO SMP seja concluído.
O deadlock requer um disco SATA conectado a um expander. Durante sas_resume_ha() -> sas_drain_work(), DISCE_RESUME -> sas_resume_sata() -> ata_sas_port_resume() solicita ATA_EH_RESET, e o reset hard para tal disco é feito via SMP PHY CONTROL (sas_ata_hard_reset() -> sas_phy_reset() -> sas_smp_phy_control() -> smp_execute_task_sg()). Resets SATA de conexão direta através de lldd_control_phy() e dispositivos SSP usam TMFs, portanto nenhum deles aciona esse problema.
Substitua o par get_sync()/put_sync() por pm_runtime_get_noresume()/pm_runtime_put(). smp_execute_task_sg() precisa apenas evitar a autosuspensão enquanto o SMP estiver em trânsito, e não deve tentar retomar o host: um retomo síncrono emitido do próprio caminho de retomo do HA é o que causa o deadlock. Além disso, quando sas_resume_ha() é executado, hw_init já reinicializou o hardware, tornando o dispositivo acessível sem essa operação.
A referência de uso ainda é necessária. O trabalho de descoberta normalmente executa dentro da referência PM (Power Management) do worker de eventos, adquirida em sas_notify_port_event() no momento da notificação e mantida até que o manipulador tenha esvaziado a fila de disco. No entanto, sas_rediscover_ex_phy() reagenda DISCE_REVALIDATE_DOMAIN a partir do próprio worker de validação, e flush_workqueue() não aguarda itens de trabalho enfileirados durante a execução; portanto, essa validação em cadeia ocorre sem uma referência PM externa - sem o get_noresume(), seu SMP poderia sofrer race condition com a autosuspensão.
Para o caminho BSG (Block Layer SCSI Generic), sas_smp_handler() é o único chamador que pode encontrar o host em autosuspensão: solicitações de expander SMP não passam por nenhuma fila de solicitação de dispositivo SCSI, portanto nada mais nesse caminho mantém o host ativo. Retome-o ali com pm_runtime_resume_and_get() e verifique o resultado.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.