🇰🇷 한글 설명
리눅스 커널의 interconnect 서브시스템에서 발생한 레이스 컨디션 취약점입니다. icc_lock과 icc_bw_lock이 분리되면서 req_list에 대한 동기화가 불충분해져, 데이터가 조작되는 동안 잘못된 포인터에 접근할 수 있습니다.
💡 쉬운 설명
컴퓨터의 핵심 부품들이 서로 통신할 때 사용하는 목록을 관리하는 과정에서 오류가 발생합니다. 두 작업이 동시에 같은 목록을 건드리면서 시스템이 엉뚱한 메모리 주소를 참조하여 충돌이 발생할 수 있습니다.
🇺🇸 원문 (English)
In the Linux kernel, the following vulnerability has been resolved:
interconnect: Don't access req_list while it's being manipulated
The icc_lock mutex was split into separate icc_lock and icc_bw_lock
mutexes in [1] to avoid lockdep splats. However, this didn't adequately
protect access to icc_node::req_list.
The icc_set_bw() function will eventually iterate over req_list while
only holding icc_bw_lock, but req_list can be modified while only
holding icc_lock. This causes races between icc_set_bw(), of_icc_get(),
and icc_put().
Example A:
CPU0 CPU1
---- ----
icc_set_bw(path_a)
mutex_lock(&icc_bw_lock);
icc_put(path_b)
mutex_lock(&icc_lock);
aggregate_requests()
hlist_for_each_entry(r, ...
hlist_del(...
<r = invalid pointer>
Example B:
CPU0 CPU1
---- ----
icc_set_bw(path_a)
mutex_lock(&icc_bw_lock);
path_b = of_icc_get()
of_icc_get_by_index()
mutex_lock(&icc_lock);
path_find()
path_init()
aggregate_requests()
hlist_for_each_entry(r, ...
hlist_add_head(...
<r = invalid pointer>
Fix this by ensuring icc_bw_lock is always held before manipulating
icc_node::req_list. The additional places icc_bw_lock is held don't
perform any memory allocations, so we should still be safe from the
original lockdep splats that motivated the separate locks.
[1] commit af42269c3523 ("interconnect: Fix locking for runpm vs reclaim")
📍 영향받는 시스템
Linux Kernel (interconnect 서브시스템을 사용하는 버전)
⚔️ 공격 벡터
로컬 공격자가 특정 시스템 호출을 통해 커널 내의 레이스 컨디션을 유도하여 메모리 손상 유발
🛡️ 대응 방법
리눅스 커널을 최신 보안 패치가 적용된 버전으로 업데이트하여 icc_bw_lock 동기화 로직을 적용해야 함
🔧 검증 코드
현재 실행 중인 커널 버전을 확인하여 해당 취약점이 해결된 패치 버전인지 확인합니다.