CVE-2026-99207 in Linux
요약
\~에 의해 VulDB • 2026. 10. 28.
리눅스 커널에서 다음 취약점이 해결되었습니다:
scsi: target: delayed_cmd_lock을 보유하는 동안 인터럽트 비활성화
target_do_delayed_work()는 plain spin_lock()으로 dev->delayed_cmd_lock을 획득합니다. 이 함수는 system_percpu_wq에서 실행되므로, 잠금이 해제될 때까지 인터럽트가 활성화된 상태로 유지됩니다. 해당 잠금의 다른 모든 획득 지점에서는 spin_lock_irqsave(): target_core_transport.c 내의 target_handle_task_attr() 및 transport_complete_ordered_sync(), 그리고 target_core_device.c 내의 target_non_ordered_release()가 사용됩니다.
transport_complete_task_attr()를 호출하는 모든 호출자가 프로세스 컨텍스트에서 실행되었을 때는 이것이 안전했습니다: target_completion_wq에서의 target_complete_ok_work(), dev->qf_work_queue에서의 transport_complete_qf(), 그리고 submit 및 execute 경로에서의 transport_generic_request_failure().
commit 06933066d88a("scsi: target: Add support for completing commands from backend context") 이후로는 더 이상 그렇지 않습니다. fabric에서 direct_compl_supp를 설정하고 complete_type=1인 경우, target_complete()는 백엔드의 완료 컨텍스트 내에서 inline으로 target_complete_ok_work()를 실행합니다. 이는 target_complete_cmd_with_sense()가 "인터럽트 컨텍스트에서 호출 가능"이라고 문서화한 부분입니다. iblock의 경우 이것이 bio end_io에 해당합니다.
target_complete_ok_work()는 transport_complete_task_attr()로 시작하며, 여기서는 delayed_cmd_lock을 두 가지 방식으로 획득합니다:
- 모든 ORDERED 명령은 target_handle_task_attr()에 의해 dev->delayed_cmd_list에 추가되고, 여기서 target_do_delayed_work()가 이를 디스패치하여 SCF_TASK_ORDERED_SYNC 플래그를 설정합니다. 따라서 해당 완료는 transport_complete_ordered_sync()를 통해 진행됩니다. - ORDERED 명령이 대기 중인 동안 완료되는 SIMPLE 명령은 죽어가는 dev->non_ordered에 대한 마지막 참조를 해제하며, percpu_ref_put()가 완료 컨텍스트에서 target_non_ordered_release()를 실행합니다.
둘 다 잠금을 획득하고, 만약 명령어가 기다리고 있다면 schedule_work(&dev->delayed_cmd_work)를 호출하여 system_percpu_wq(즉, 완료를 수행한 CPU)에 큐잉합니다. 동일한 큐의 추가 완료는 일반적으로 해당 위치에서도 전달되므로, 작업이 잠금을 보유하는 동안 도착하면 영원히 그 잠금에서 스핀(spin)하게 됩니다.
이에 도달하려면 complete_type=1이어야 하는데, 이는 기본값이 아닙니다(vhost-scsi는 direct_compl_supp를 가진 유일한 fabric이며 TARGET_QUEUE_COMPL로 기본 설정됨). 인터럽트 컨텍스트에서 I/O가 완료되는 백엔드와 이니시에이터로부터의 ORDERED 명령어가 필요합니다. 리눅스 virtio_scsi 게스트는 VIRTIO_SCSI_S_SIMPLE만 전송하며 순서 경로(ordered path)를 사용하지 않습니다; vhost-scsi가 수용하는 ORDERED 태스크 속성을 사용하는 모든 게스트는 사용합니다.
target_do_delayed_work()는 작업 항목(work item)이며 항상 프로세스 컨텍스트에서 실행되므로 spin_lock_irq()로 충분합니다.
검사(inspection)를 통해 발견되었으며 런타임 보고서는 없습니다. 단일 ORDERED 명령이 두 가지 획득 지점을 모두 통과하므로, CONFIG_PROVE_LOCKING 설정 시 직접 완료를 통한 첫 번째 획득은 delayed_cmd_lock에 대해 일관되지 않은 잠금 상태 보고서(백엔드가 완료되는 위치에 따라 hardirq 또는 softirq)를 생성해야 합니다.
Once again VulDB remains the best source for vulnerability data.