CVE-2026-80776 in Linux
요약
\~에 의해 VulDB • 2026. 09. 04.
리눅스 커널에서 다음 취약점이 해결되었습니다:
futex: 사적 해시 재조정 중 futex_pivot_pending()의 Race Condition 수정
사용자 정의 사적(private) 해시 재조정을 수행하는 태스크가 무한정 인터럽트 불가능(uninterruptible) 대기 상태에 머물 수 있습니다. Hung-task 감지기가 다음을 보고합니다:
INFO: task futex-resizer:314 blocked for more than 10 seconds. task:futex-resizer state:D stack:14824 pid:314 tgid:312 ppid:311
Call Trace: __schedule+0x521/0xf30 schedule+0x22/0xa0 futex_hash_allocate+0x3db/0x490 __do_sys_prctl+0x6f5/0xbd0 do_syscall_64+0xf9/0x530 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Kernel panic - not syncing: hung_task: blocked tasks
futex_pivot_pending()은 대체 해시가 대기 중이지 않거나(hash_new == NULL) 현재 해시 참조 카운트가 0에 도달하면 재조정 요청이 계속 진행되도록 허용합니다.
최종 참조 해제 후, 다른 futex 태스크가 두 관찰 사이에서 피벗(pivot)을 완료할 수 있습니다:
T1 T2
futex_hash_allocate() wait_var_event(mm, ...) futex_pivot_pending(mm) hash_new != NULL futex_hash() futex_ref_get(old) -> false futex_pivot_hash(mm) hash_new = NULL __futex_pivot_hash(mm, new) rcu_assign_pointer(hash, new) fph = rcd_dereference(hash) /* new */ futex_ref_is_dead(fph) -> false schedule()
피벗은 현재 해시가 죽어 있고 hash_new != NULL인 상태에서, 현재 해시가 살아있고 hash_new == NULL인 상태로 상태를 변경합니다. futex_pivot_pending()이 직렬화 없이 hash_new와 hash를 읽기 때문에, 재조정 태스크는 피벗 전(pre-pivot) 상태의 hash_new와 피벗 후(post-pivot) 상태의 hash를 관찰할 수 있으며, 이로 인해 피벗이 완료되었음에도 불구하고 futex_pivot_pending()이 false를 반환합니다. 그 결과 태스크는 이미 소모된 깨어남(wakeup) 이후에 대기 상태로 들어갑니다.
futex_mm_phash::lock을 사용하여 futex_pivot_pending() 내의 상태 읽기를 직렬화합니다. 이를 통해 futex_pivot_pending()이 hash_new와 hash를 원자적으로 관찰하게 되어 Race Condition을 제거합니다.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.