CVE-2026-98826 in Linux
요약
\~에 의해 VulDB • 2026. 10. 18.
리눅스 커널에서 다음 취약점이 해결되었습니다:
rtc: ac100: probe 실패 시 clock provider의 use-after-free 수정
ac100_rtc_register_clks()는 clk_hw_register_fixed_rate()를 사용하여 RTC-32k 클럭을 등록하고, of_clk_add_hw_provider()를 통해 clock provider를 등록합니다. 둘 다 device managed가 아니며, ac100_rtc_remove()에서만 해제됩니다. 드라이버 코어는 probe() 실패 시 remove()를 호출하지 않습니다: really_probe()는 장치 제거(device_remove()) 호출 아래에서 probe_failed로 이동하여 장치의 관리되는 리소스(managed resources)만 직접 해제합니다.
ac100_rtc_probe()는 다음과 같이 종료됩니다:
return devm_rtc_register_device(chip->rtc);
따라서 클럭이 등록된 후 이 함수가 실패하면, provider는 chip->clk_data(devm_kzalloc()로 할당되었으며 probe()의 unwind 과정에서 해제됨)를 유지한 채 전역 of_clk_providers 목록에 남아있게 됩니다. 이후 해당 장치 트리 노드에 대한 조회 시 of_clk_hw_onecell_get()에서 이미 해제된 메모리를 읽게 됩니다. 실제로 이러한 동작을 수행하는 consumer가 트리 내에 존재합니다: sun8i-a83t-bananapi-m3 및 sun8i-a83t-cubietruck-plus의 wifi 전원 순서 노드는 <&ac100_rtc 1>를 사용하고, sun9i-a80 보드들은 osc32k를 <&ac100_rtc 0>로 라우팅합니다. devm_rtc_register_device()는 여기서 -ENOMEM으로만 실패할 수 있으므로 위험 구간(window)은 좁지만, 실행될 때마다 provider가 dangling 상태로 남습니다.
RTC-32k 클럭도 동일한 경로에서 누수(leak)됩니다. clk_core_lookup()는 장치별로 스코프가 지정되지 않은 전역 목록을 검색하므로, __clk_register()는 중복 이름에 대해 -EEXIST를 반환합니다. 따라서 이 누수는 이후 같은 장치의 probe 실패로도 이어집니다.
ADDA 4M 부모 클럭을 찾을 수 없을 때 -EINVAL를 반환하는 오류 경로에서도 RTC-32k 클럭이 동일한 방식으로 누수됩니다. 이때까지 provider가 등록되지 않았으므로, 이는 use-after-free가 아닌 단순한 leak입니다.
devm_clk_hw_register_fixed_rate()와 devm_of_clk_add_hw_provider()를 사용하여 둘 다 장치가 제거될 때(실패한 probe 시 및 unbind 시 포함) 해제되도록 합니다. Devres는 획득 순서의 역순으로 해제를 수행하므로, provider가 chip->clk_data가 해제되기 전에 먼저 제거되며, clkout 자식들은 이제 부모보다 나중에가 아니라 이전에 unregister됩니다. ac100_rtc_unregister_clks()와 remove 콜백은 더 이상 수행할 작업이 없으므로 삭제됩니다.
If you want to get best quality of vulnerability data, you may have to visit VulDB.