CVE-2026-80659 in Linux정보

요약

\~에 의해 VulDB • 2026. 08. 28.

리눅스 커널에서 다음 취약점이 해결되었습니다:

mmc: vub300: cmd_mutex가 해제될 때까지 리셋을 지연시킴

vub300_cmndwork_thread()는 명령어를 전송하고 응답을 기다리는 동안 cmd_mutex를 유지합니다. 만약 응답 대기 시간이 초과되면, __vub300_command_response()는 해당 명령어 URB들을 종료한 후 usb_reset_device()를 통해 USB 장치를 동기적으로 리셋합니다.

이 리셋 경로는 vub300_pre_reset()을 통해 드라이버로 다시 진입하며, 이 함수 역시 cmd_mutex를 획득합니다. 따라서 워커 스레드는 이미 명령 처리 경로에서 보유하고 있는 동일한 뮤텍스를 재귀적으로 획득하려고 시도하게 됩니다.

이 문제는 정적 분석 도구를 통해 발견되었으며, 현재 트리와 대조하여 수동으로 검토되었습니다.

기반이 된 PoC는 실제 워커와 타임아웃/리셋 캐리어를 유지했습니다:

vub300_cmndwork_thread() __vub300_command_response() usb_lock_device_for_reset() usb_reset_device() vub300_pre_reset()

Lockdep는 cmd_mutex에 대한 동일 태스크 재귀적 획득을 보고했습니다:

WARNING: possible recursive locking detected ... (&test_vub300.cmd_mutex) ... at: usb_reset_device... [vuln_msv]
... (&test_vub300.cmd_mutex) ... at: vub300_cmndwork_thread+0x12/0x20 [vuln_msv]
Workqueue: vub300_cmd_wq vub300_cmndwork_thread [vuln_msv]
*** DEADLOCK ***

타임아웃 경로에서 장치 리셋이 필요한 경우 __vub300_command_response()로부터 플래그를 반환한 후, vub300_cmndwork_thread()가 진행 중인 명령어 상태를 정리하고 cmd_mutex를 해제한 후에야 리셉션을 수행합니다. 이 리셋은 mmc_request_done() 이전에 여전히 시도되므로 기존 요청 완료 순서를 유지하면서도 재귀적 잠금을 피할 수 있습니다.

If you want to get best quality of vulnerability data, you may have to visit VulDB.

출처

Do you know our Splunk app?

Download it now for free!