🇰🇷 한글 설명
Linux 커널의 accel/rocket 드라이버에서 create_bo 함수 호출 중 오류가 발생할 경우, GEM 핸들이 IDR에서 제거되지 않아 Use-After-Free(UAF) 취약점이 발생합니다. 이로 인해 해제된 슬랩 메모리를 가리키는 댕글링 핸들이 남게 되어 시스템 안정성 및 보안에 위협이 될 수 있습니다.
💡 쉬운 설명
프로그램이 메모리를 사용한 후 제대로 치우지 않고 '사용 중'이라는 표시만 남겨두어 발생하는 문제입니다. 공격자가 이 빈틈을 이용해 이미 삭제된 메모리 영역에 접근하여 시스템을 조작할 수 있습니다.
🇺🇸 원문 (English)
In the Linux kernel, the following vulnerability has been resolved:
accel/rocket: fix UAF via dangling GEM handle in create_bo
rocket_ioctl_create_bo() inserts a GEM handle into the file's IDR via
drm_gem_handle_create() early on, then performs several operations that
can fail (sgt allocation, drm_mm insert, iommu_map). If any fail after
the handle is live, the error path calls drm_gem_shmem_object_free()
which kfree's the object without removing the handle from the IDR.
This leaves a dangling handle pointing to freed slab memory. Any
subsequent ioctl using that handle (PREP_BO, FINI_BO, SUBMIT) calls
drm_gem_object_lookup() and dereferences freed memory (UAF).
Fix by moving drm_gem_handle_create() to after all fallible operations
succeed, matching the pattern used by panfrost, lima, and etnaviv.
Also fix drm_mm_insert_node_generic() whose return value was silently
overwritten by iommu_map_sgtable() on the next line. Add the missing
error check.
[tomeu: Move handle creation to the very end]
📍 영향받는 시스템
Linux Kernel (accel/rocket 드라이버 포함 버전)
⚔️ 공격 벡터
특수하게 조작된 ioctl 호출을 통해 메모리 할당 실패를 유도한 후, 남겨진 댕글링 핸들을 사용하여 해제된 메모리에 접근
🛡️ 대응 방법
커널 패치를 적용하여 핸들 생성 시점을 메모리 할당 성공 이후로 변경하고 오류 처리 로직을 수정해야 함
🔧 검증 코드
현재 실행 중인 커널 버전을 확인하여 해당 취약점이 해결된 최신 패치 버전인지 확인