CVE-2026-89857 in Linux
요약
\~에 의해 VulDB • 2026. 09. 16.
Linux 커널에서 다음 취약점이 해결되었습니다:
scsi: qla2xxx: NVMe LS reject 전송 시 qpair 잠금 유지
qla_nvme_ls_reject_iocb()는 __qla2x00_alloc_iocbs()(하드웨어 잠금이 보유되어 있다고 가정함)와 qla2x00_start_iocbs()(링을 진행하고 요청 인 도어벨을 울림)를 통해 할당 및 요청 링의 포인터를 전진시키지만, 자체적으로는 어떤 잠금도 획득하지 않습니다. 이 함수의 호출자 중 두 개는 생산자(producer) 잠금이 보유된 상태가 아닌 채로 이를 호출합니다:
- qla_nvme_xmt_ls_rsp(): NVMe-FC .xmt_ls_rsp 전송 콜백으로, 에러 경로에서 실행됨 - qla2xxx_process_purls_pkt(): purex 작업/DPC 컨텍스트에서 실행됨
둘 다 ha->base_qpair를 사용하며, 해당 qp_lock_ptr는 hardware_lock을 가리키므로 기본 링에서의 일반 I/O 제출과 동시에 실행되어 링 생산자 상태를 손상시킬 수 있으며, 이로 인해 명령이 중복되거나 손실될 수 있습니다. 세 번째 호출자인 qla2xxx_process_purls_iocb()는 qpair 잠금이 이미 보유된 상태인 qla24xx_process_response_queue() 내부에서 실행되므로 안전합니다. 또한 이것이 바로 해당 헬퍼 함수 내에서 잠금을 획득할 수 없는 이유이기도 합니다(응답 경로에서 하드웨어 잠금을 재귀적으로 다시 획득하게 되기 때문).
잠금 없이 호출되는 두 곳에 qp_lock_ptr를 적용하고, 이 헬퍼가 caller-locked(호출자가 잠금을 보유함)임을 문서화합니다. 둘 다 프로세스 컨텍스트에서 실행되므로 spin_lock_irqsave()가 사용되며, 잠금 영역 내에서는 어떤 동작도 블로킹되지 않습니다.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.