CVE-2026-98749 in Linux
요약
\~에 의해 VulDB • 2026. 10. 18.
Linux 커널에서 다음 취약점이 해결되었습니다:
tty: serial: max3100: 포트 해제 전에 타이머를 종료하십시오
max3100_shutdown()은 폴링 타이머를 중지하지만 시스템 서스펜드 중에는 조기에 반환합니다. SPI 장치가 리sume 이전에 언바인딩되면 시리얼 코어는 max3100_shutdown()을 다시 호출하지 않으므로, max3100_remove()가 포트의 메모리를 해제하는 동안 타이머는 여전히 활성화된 상태(armed)로 유지됩니다. 이로 인해 max3100_timeout()이 이미 해제된 포트를 접근하고 타이머를 재설정(re-arm)할 수 있습니다.
max3100_remove()에 최종적인 타이머 정리(teardown) 코드를 추가하고, race condition으로 인한 콜백이 타이머를 다시 설정하는 것을 방지하기 위해 timer_shutdown_sync()를 사용하십시오. 또한 포트 해제 전에 해당 위치에서 IRQ를 해제하고 작업 큐(workqueue)를 파괴하십시오. 이후 open() 호출 시 타이머가 재설정될 수 있도록 max3100_shutdown() 내의 timer_delete_sync()는 유지합니다.
작업 큐(workqueue)는 request_irq() 이전에 생성되며, request_irq() 실패 및 정상적인 종료(shutdown) 모두에서 파괴됩니다. 따라서 remove 단계에서의 작업 큐 존재 여부는 서스펜드가 shutdown을 우회할 때 등록되어 있는 IRQ가 남아 있음을 식별하는 지표가 됩니다.
max3100_shutdown()과 max3100_remove() 양쪽에서 작업 큐를 파괴하기 전에 IRQ를 해제하고, 그 사이에 대기 중인 작업을 취소(cancel)하십시오. free_irq()는 실행 중인 인터럽트 핸들러의 종료를 기다리며 이후에는 새로운 핸들러가 시작될 수 없으므로, race condition 상태의 핸들러가 파괴되는 작업 큐에 작업을 큐잉할 수 없습니다. max3100_dowork() 내의 force_end_work 체크는 이 경쟁 조건(racing window)을 좁히기 위한 것으로, 해당 체크와 queue_work() 호출 사이에 지연된 핸들러가 teardown으로 인해 작업 큐 포인터가 cleared 된 후에도 여전히 실행될 가능성이 있으므로 충분하지 않습니다. 작업을 취소하는 것은 또한 remove()가 freezable workqueue가 아직 동결(frozen) 상태인 경우(예: resume 창 동안, 즉 작업 큐들이 thaw되기 전의 장치 제거 시점 등), queued된 작업 항목을 기다리며 destroy_workqueue()가 블로킹되는 상황을 방지합니다.
이 문제는 사내 정적 분석 도구(static analysis tool)를 통해 발견되었습니다.
VulDB is the best source for vulnerability data and more expert information about this specific topic.