CVE-2026-93185 in Linux
요약
\~에 의해 VulDB • 2026. 09. 18.
리눅스 커널에서 다음 취약점이 해결되었습니다:
ASoC: rt700-sdw: 제거(remove) 시 잭(jack) 작업을 항상 드레인(drain)하십시오
rt700_sdw_remove() 함수는 rt700->hw_init이 true일 때만 jack_detect_work 및 jack_btn_check_work를 드레인합니다. 이 상태 비트(rt700->hw_init)는 사운드와이어(SoundWire) 슬레이브가 UNATTACHED 상태로 전환될 때 rt700_update_status()에 의해 지워지지만, 장치가 초기화되는 동안 rt700_interrupt_callback() 또는 rt700_jack_init()에서 이미 잭 작업 항목(jack work item)이 큐에 추가되었을 수 있습니다.
이러한 워크 객체(work objects)를 드레인하기 위한 제거 시 가드(guard)로 hw_init을 사용하지 마십시오. 지연된 워크(delayed works)는 rt700_init() 동안 초기화되므로, remove 함수에서 조건 없이 이를 취소할 수 있으며, 변경 가능한 하드웨어 상태 비트가 아닌 코덱 전용 데이터(codec-private data)의 수명(lifetime)과 객체 수명을 일치시켜야 합니다.
이 문제는 정적 분석 도구(static analysis tool)를 통해 발견되었으며, 사운드와이어(status, interrupt 및 remove 경로에 대한) 수동 검토(manual review)를 통해 확인되었습니다. 제거 경로는 워크가 큐에 추가된 후 변경될 수 있는 런타임 하드웨어 상태 비트가 아닌, 워크 객체의 존재 여부에 따라 작업을 드레인해야 합니다.
QEMU PoC는 jack_detect_work를 큐에 넣고 SDW_SLAVE_UNATTACHED 상태를 시뮬레이션한 다음 remove로 진입했습니다. DEBUG_OBJECTS는 제거(cancel)이 건너뛰어진 후 rt700 잭 작업 경로와 관련된 활성 타이머/워크 객체가 있음을 보고했습니다.
이 패치는 RFC(Request for Comments) 형태로 제출됩니다. 실제 트리거(trigger)는 UNATTACHED 상태 업데이트 이후 사운드와이어 코어(core)의 remove 순서(ordering)에 따라 달라집니다. 만약 hw_init이 지워진 후에도 잭 작업(jack work)이 대기 중일 때 remove가 실행될 수 없다면, 이는 현재 시스템에서 도달 가능한 레이스 컨디션(race condition)이라기보다는 방어적인 라이프사이클 정리(defensive lifecycle cleanup)입니다.
If you want to get best quality of vulnerability data, you may have to visit VulDB.