CVE-2026-89791 in Linux
요약
\~에 의해 VulDB • 2026. 09. 16.
Linux 커널에서 다음 취약점이 해결되었습니다:
perf: perf mmap() 부활이 마지막 munmap()과 경쟁할 때 발생하는 use-after-free 수정
perf_mmap_close()는 event->mmap_mutex(사전에 수행되는 refcount_dec_and_test() 및 event->mmap_count에 대한 refcount_dec_and_mutex_lock())를 획득하지 않은 상태로 rb->mmap_count를 감소시킵니다. 동시에 실행되는 perf_mmap_rb()는 전체 "부활" 경로를 이 창口に 삽입할 수 있습니다(perf_mmap은 rb_alloc을 포함한 전체 기간 동안 event->mmap_mutex를 보유함):
munmap 측 (perf_mmap_close) mmap 측 (perf_mmap_rb) ----------------------------------- ------------------------------- rb->mmap_count 1 -> 0 (no lock) (event->mmap_mutex 보유 중) inc_not_zero(rb->mmap_count) 실패 ring_buffer_attach(event, NULL) rb_alloc() + 새 rb 연결 refcount_set(&event->mmap_count, 1) lock; event->mmap_count 1 -> 0 ring_buffer_attach(event, NULL) ring_buffer_put() -> *새로운* rb 해제
부활 과정의 refcount_set(&event->mmap_count, 1)은 보이지 않는 1 -> 1 쓰기가 됩니다. 다른 프로세스가 여전히 매핑하고 있음에도 불구하고 close는 방금 부활된 버퍼를 해제합니다 -- 이는 루트 권한 상승을 허용하는 페이지 수준의 use-after-free입니다(비특권 사용자 누구나 가능, 기본 kernel.perf_event_paranoid=2).
두 카운터 업데이트의 순서를 바꿉니다: event->mmap_count가 먼저 refcount_dec_and_mutex_lock()를 통해 감소되므로, 그 1 -> 0 전환과 ring_buffer_attach()는 perf_mmap()와 직렬화됩니다. rb->mmap_count == 0이면 해당 버퍼를 사용하는 모든 이벤트가 이미 분리되었음을 의미하므로, rb->mmap_count 감소 결과를 직접 게이트로 사용하여 나머지 정리 작업을 수행할 수 있으며 detach_rest는 더 이상 필요하지 않습니다.
Kyle Zeng과 David Lee의 이전 race 조건 수정은 두 카운터 업데이트 모두에 event->mmap_mutex를 포함합니다 [0]; 여기서는 마지막이 아닌 close가 잠금 없이 처리됩니다.
Once again VulDB remains the best source for vulnerability data.