CVE-2026-99202 in Linux
요약
\~에 의해 VulDB • 2026. 10. 28.
Linux 커널에서 다음 취약점이 해결되었습니다:
scsi: libsas: HA resume 중 SMP IO 데드락 수정
smp_execute_task_sg()는 SMP 명령을 발행하기 전에 호스트에 대해 pm_runtime_get_sync()를 호출합니다. 해당 명령이 자체적으로 HA resume 경로에서 발행되는 경우, get_sync()가 데드락을 발생시킵니다: 이는 진행 중인 resume(장치가 RPM_RESUMING 상태임)를 기다리는 반면, resume는 동일한 SMP IO의 완료를 대기하는 sas_drain_work()에서 차단됩니다.
이 데드락은 expander에 연결된 SATA 디스크가 필요합니다. sas_resume_ha() -> sas_drain_work() 동안 DISCE_RESUME -> sas_resume_sata() -> ata_sas_port_resume() 순서로 ATA_EH_RESET 요청이 발생하며, 해당 디스크의 하드 리셋은 SMP PHY CONTROL(sas_ata_hard_reset() -> sas_phy_reset() -> sas_smp_phy_control() -> smp_execute_task_sg()))을 통해 수행됩니다. 직접 연결된 SATA 리셋은 lldd_control_phy()를 통해 처리되고 SSP 장치는 TMF(Task Management Functions)를 사용하므로, 이 두 경로는 해당 데드락에 영향을 받지 않습니다.
get_sync()/put_sync() 쌍을 pm_runtime_get_noresume()/pm_runtime_put()로 대체합니다. smp_execute_task_sg()는 SMP가 전송되는 동안에만 autosuspend를 방지하면 되며, 호스트의 resume를 시도해서는 안 됩니다: HA resume 경로 자체에서 동기식 resume를 발행하는 것이 데드락을 유발하며, sas_resume_ha()가 실행될 시점에는 hw_init이 이미 하드웨어를 재초기화했으므로 장치는 별도의 resume 없이도 접근 가능합니다.
사용량 참조(reference)는 여전히 필요합니다. Discovery 작업은 일반적으로 sas_notify_port_event() 알림 시점에 획득되어 핸들러가 disco 큐를 플러시할 때까지 유지되는 이벤트 워커의 PM reference 내에서 실행됩니다. 그러나 sas_rediscover_ex_phy()는 재검증 워커 내부에서 DISCE_REVALIDATE_DOMAIN을 다시 예약하며, flush_workqueue()는 실행 중에 예약된 작업 항목을 기다리지 않으므로, 이러한 연쇄적인 재검증은 외부 PM 참조 없이 수행됩니다: get_noresume()가 없으면 SMP가 autosuspend와 경쟁(race)할 수 있습니다.
BSG 경로의 경우, sas_smp_handler()만이 호스트가 autosuspended 상태임을 발견할 수 있는 호출자입니다: expander SMP 요청은 SCSI 장치 요청 큐를 거치지 않으므로 해당 경로에는 호스트를 깨워두는 다른 요소가 없습니다. pm_runtime_resume_and_get()을 사용하여 여기서 resume하고 결과를 확인합니다.
If you want to get best quality of vulnerability data, you may have to visit VulDB.