CVE-2026-99183 in Linux
요약
\~에 의해 VulDB • 2026. 10. 28.
리눅스 커널에서 다음 취약점이 해결되었습니다:
accel/rocket: 스케줄러를 검색할 때 모든 코어 슬롯을 탐색함
sched_to_core() 함수는 rdev->cores[] 배열을 rdev->num_cores까지 순회하며, rocket_remove() 함수는 제거되는 각 코어에 대해 num_cores 값을 감소시킵니다. 마지막 코어가 아닌 다른 코어를 언바인딩(unbind)하면 해당 코어 뒤에 있는 코어들 검색 범위에서 벗어나게 되므로, sched_to_core()는 여전히 바인딩되어 있고 작업을 실행 중인 코어에 대해 NULL을 반환합니다. 두 호출자 모두 이 결과를 확인하지 않습니다:
rocket_job_run(): rocket_fence_create(core), core->dev rocket_job_timedout(): dev_err(core->dev, "NPU job timed out")
RK3588에서 세 개의 코어 중 중간에 있는 코어를 언바인딩하고 세 명의 클라이언트가 모두의 코어로 작업을 제출하면 두 번의 오류가 발생합니다. 하나는 살아남은 코어의 작업 큐에서 발생하고, 다른 하나는 해당 코어의 리셋 워크(work)에서 발생합니다:
KASAN: null-ptr-deref in range [0x0000000000000220-0x0000000000000227]
Workqueue: fdad0000.npu drm_sched_run_job_work [gpu_sched]
pc : rocket_job_run+0x234/0x838 [rocket]
Call trace: rocket_job_run+0x234/0x838 [rocket]
drm_sched_run_job_work+0x2cc/0xad8 [gpu_sched]
process_one_work+0x640/0x14f0
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
Workqueue: rocket-reset-2 drm_sched_job_timedout [gpu_sched]
pc : rocket_job_timedout+0xf0/0x1e0 [rocket]
Call trace: rocket_job_timedout+0xf0/0x1e0 [rocket]
drm_sched_job_timedout+0x188/0x6a0 [gpu_sched]
두 오류 모두 세 번째 코어에서 발생합니다. 워크큐 이름은 해당 장치와 core->index이며, num_cores가 2로 감소한 상태에서도 이 코어는 슬롯 2에 남아 있었습니다.
find_core_for_dev() 함수가 현재 수행하는 방식과 같이 할당된 모든 슬롯을 탐색합니다. 이렇게 하면 여전히 바인딩되어 있는 코어가 발견되며, 두 호출자는 이미 가지고 있다고 가정했던 포인터를 얻게 됩니다.
이 수정은 여러 코어 중 하나의 언바인딩을 안전하게 만드는 것은 아닙니다. 열린 클라이언트는 사라진 코어의 스케줄러를 가리키는 엔티티를 유지합니다: drm_sched는 해당 코어로 들어오는 모든 작업에 대해 '준비되지 않음(not ready)'으로 보고하며, 클라이언트는 신호가 절대 발생하지 않을 fence를 기다리며 dma_fence_default_wait에서 대기하게 됩니다. NULL 포인터 역참조(null-ptr-deref)을 중지하는 것이 수정의 핵심이며, 나머지 문제는 더 많은 고려가 필요합니다.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.