CVE-2026-99184 in Linux
요약
\~에 의해 VulDB • 2026. 10. 28.
리눅스 커널에서 다음 취약점이 해결되었습니다:
accel/rocket: 코어가 제거될 때 모든 슬롯을 검색함
rocket_remove()는 제거하는 각 코인에 대해 rdev->num_cores를 감소시키지만, find_core_for_dev()은 0부터 num_cores - 1까지의 슬롯을 검색합니다. 따라서 바인딩된 순서대로 코어를 언바인딩하면 마지막 코어가 손실됩니다: 해당 코어가 제거될 때쯤이면 검색 범위가 이미 그 슬롯보다 좁아졌기 때문에, find_core_for_dev()은 -1을 반환하고 rocket_remove()는 아무 작업도 수행하지 않고 중단합니다.
num_cores가 0에 도달하지 않으므로 rocket_device_fini()이 실행되지 않으며, 파일 스코프의 rdev는 사라져가는 장치를 계속 가리킵니다. 코어를 다시 바인딩하면 stale(구식) 카운트에서 시작되는데, 이는 rocket_probe()가 채울 슬롯으로 rdev->num_cores를 사용하기 때문입니다. RK3588에서는 세 개의 코어를 설명하므로, 두 번째 라운드에서는 slots 1, 2 및 3에 도달하지만 rdev->cores는 세 개 분량만 할당되었습니다:
rocket fdab0000.npu: Rockchip NPU core 1 version: 1179210309 rocket fdac0000.npu: Rockchip NPU core 2 version: 1179210309 rocket fdad0000.npu: Rockchip NPU core 3 version: 1179210309
rdev->cores[3]에 대한 쓰기는 배열의 끝을 벗어난 위치입니다.
트리 내에서는 코어 배열을 자주 읽지 않아서 현재로는 오버런이 조용히 발생합니다. 이 문제는 이를 기반으로 devfreq 시리즈를 테스트하는 동안 발견되었는데, 여기서 워커는 초당 몇 번씩 모든 코어를 순회하며 UBSAN은 오버런된 엔트리를 읽어낸 첫 번째 bool 값을 포착했습니다:
UBSAN: invalid-load in drivers/accel/rocket/rocket_devfreq.c:47:10 load of value 5 is not a valid value for type '_Bool' Workqueue: devfreq_wq devfreq_monitor
할당된 슬롯의 수를 기록하고 모든 슬롯을 검색합니다. 그러면 제거 시 모든 코어가 발견되고, num_cores가 0에 도달하며, 장치가 해제되고 이후 바인딩은 깨끗한 rdev에서 시작됩니다.
이 수정으로 인해 여러 코어 중 하나의 코어를 언바인딩하는 작업이 성공적으로 수행되지는 않습니다. probe는 여전히 채울 슬롯으로 num_cores를 사용하므로, 형제 코어가 바인딩된 상태로 단일 코어를 재바인딩하면 이미 사용되는 슬롯을 덮어쓰게 되며, rocket_open()은 해당 위치에 무언가가 있는지 여부와 상관없이 cores[0]에 접근합니다. 이 두 가지 문제는 수정 사항이 담아야 할 내용보다 더 많은 고려가 필요합니다.
Orange Pi 5 Plus에서 세 코어를 모두 언바인딩하고 재바인딩하여 발견되었습니다. 이 패치를 적용하면, 25번의 unbind/rebind 라운드와 5번의 모듈 언로드/재로드 라운드가 깨끗하게 실행됩니다: 코어는 바인딩 순서에 관계없이 항상 slots 0, 1 및 2에 위치하며, 공유 공급원은 각 라운드 후에 단일 사용자에게 다시 돌아갑니다.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.