CVE-2026-89875 in Linux
요약
\~에 의해 VulDB • 2026. 09. 16.
Linux 커널에서 다음 취약점이 해결되었습니다:
media: ti: vpe - 스트림 해제 전에 과부하 복구 작업을 안정화(quiesce)함
VIP 과부하 복구 작업자는 FIFO 오버플로우가 감지될 때 하드 IRQ 핸들러로부터 활성화되며, list-complete 경로는 VPDMA 리스트의 프라이빗 포인터를 통해 스트림을 조회합니다. 둘 다 스트림, 포트 및 디바이스 상태에 접근합니다. 복구 작업자는 또한 파서와 VPDMA를 재설정하고, 설명자(descriptor) 목록을 다시 채우며, 각 리스트별 IRQ들을 활성화합니다.
vip_stop_streaming()은 각 리스트별 IRQ를 마스크하고 지웁니다. 그러나 하드 IRQ 핸들러와의 동기화를 수행하지 않으며 recovery_work도 비활성화하지 않습니다. 따라서 스트림이 해제될 때 이미 큐에 대기 중인 recovery_work나 실행 중(list in flight)인 list-complete IRQ는 리소스가 해제된 후에도 여전히 스트림을 역참조(dereference)할 수 있습니다: 설명자 목록은 파일 릴리스 시 vip_release_stream()에서 해제되고, 스트림 자체는 언바운드/제거 시 free_stream()에 의해 해제됩니다.
스트림 소유 리소스가 해제되기 전에 공유 헬퍼 함수인 vip_quiesce_stream()을 통해 두 해지 지점(teardown points) 모두에서 복구 작업자와 IRQ 핸들러를 드레인합니다. disable_work_sync()는 대기 중인 recovery_work를 취소하고, 실행 중인 인스턴스를 드레인하며, 비활성화 깊이를 높입니다. 따라서 경합(racing) 상태의 IRQ 핸들러가 발행한 이후 schedule_work() 호출은 워크큐 스케줄러에서 거부됩니다: disable_work_sync()이 적용된 후에는 recovery_work를 다시 큐에 넣을 수 없습니다. 작업자는 disable_work_sync()가 반환하기 전에 여전히 각 리스트별 IRQ들을 활성화할 수 있습니다; 이때 disable_irqs()는 해당 소스를 마스크하고, synchronize_irq()는 스트림 상태를 역참조하는 실행 중인(in-flight) 핸들러의 종료를 기다립니다. vip_stop_streaming()에서 이 헬퍼 함수는 파서가 중지되기 전에 실행됩니다. 왜냐하면 disable_work_sync()에 의해 드레인된 작업자가 종료하기 전에 파서를 다시 활성화할 수 있으며, 이는 중지를 무효화할 수 있기 때문입니다. recovery_work는 비활성화된 상태로 생성되며, vip_start_streaming()에서 IRQ 이전에 활성화되어 스트리밍 라이프사이클 전반에 걸쳐 해지 시의 비활성화와 짝을 이룹니다.
이 문제는 사내 정적 분석 도구를 통해 발견되었으며 수동 코드 검토를 통해 확인되었습니다.
If you want to get best quality of vulnerability data, you may have to visit VulDB.