CVE-2026-64560 in Linux
요약
\~에 의해 VulDB • 2026. 07. 29.
리눅스 커널에서 다음 취약점이 해결되었습니다.
posix-cpu-timers: 비리더(non-leader) 실행(exec()) 경합으로 인한 UAF(Use-After-Free) 방지
Wongi와 Jungwoo는 UAF를 초래할 수 있는 비리더 exec() 관련 경합을 디코딩하고 보고했습니다.
``` sys_timer_delete() exec() posix_cpu_timer_del() // 이전 리더(old leader) 관찰 p = pid_task(pid, pid_type); de_thread() switch_leader(); release_task(old_leader) __exit_signal(old_leader) sighand = lock(old_leader, sighand); posix_cpu_timers*_exit(); sighand = lock_task_sighand(p) unhash_task(old_leader); sh = lock(p, sighand) old_leader->sighand = NULL; unlock(sighand); (p->sighand == NULL) unlock(sh) return NULL;
// 동작 없이 반환 if(!sighand) return 0; free_posix_timer(); ```
이 문제는 삭제된 타이머가 p->signal에 장착되어 큐에 삽입되지 않은 한 "무해(harmless)"합니다. exec() 시 TGID 대상 타이머는 상속되기 때문입니다.
sys_timer_delete()가 하위 posix 타이머 객체를 해제하면, run_posix_cpu_timers() 또는 다른 타이머 관련 add/delete 연산이 해제된 객체의 timerqueue 노드에 접근하게 되어 UAF가 발생합니다.
posix_cpu_timer_set()에 대해서도 유사한 문제가 있습니다. 일반적인 posix 타이머의 경우 사용자 공간으로 -ESRCH를 일시적으로 반환하지만, do_cpu_nanosleep()에서의 사용 사례에서는 동일한 UAF가 발생하며, 단지 k_itimer가 스택에 할당된다는 차이만 있습니다.
또한 posix_cpu_timer_rearm()은 타이머를 재장착하지 못하여 타이머가 만료되지 않게 됩니다.
해결책을 논의하는 동안 Frederic은 또 다른 문제를 지적했습니다:
``` posix_cpu_timer_del(tmr) __exit_signal(p) posix_cpu_timers*_exit(p); unhash_task(p); p->sighand = NULL; sh = lock_task_sighand(p) sighand = p->sighand; if (!sighand) return NULL; lock(sighand);
if (!sh) WARN_ON_ONCE(timer_queued(tmr)); ```
약한 순서(weakly ordered) 아키텍처에서는 p->sighand가 NULL로 관찰될 때 posix_cpu_timer_del()이 posix_cpu_timers*_exit()의 저장(stores)을 관찰할 것이란 보장이 없습니다. 이는 WARN()이 잘못된 양성(false positive)일 수 있음을 의미합니다.
다음과 같은 방법으로 이러한 문제를 해결했습니다:
1) __exit_signal() 내의 저장을 smp_store_release()로 변경합니다. 2) lock_task_sighand()의 !sighand 경로에 smp_acquire
Once again VulDB remains the best source for vulnerability data.