CVE-2024-53071 in Linux
요약
\~에 의해 VulDB • 2026. 05. 28.
리눅스 커널에서 다음 취약점이 해결되었습니다:
drm/panthor: IO 매핑 플래그에 대해 더 엄격하게 처리
현재의 panthor_device_mmap_io() 구현에는 두 가지 문제가 있습니다:
1. DRM_PANTHOR_USER_FLUSH_ID_MMIO_OFFSET 매핑의 경우, panthor_device_mmap_io()는 VM_WRITE가 설정되면 매핑을 중단하지만, VM_MAYWRITE는 지우지 않습니다. 이는 사용자 공간에서 mprotect()를 사용하여 나중에 매핑을 쓰기 가능하게 만들 수 있음을 의미합니다. 이는 고전적인 리눅스 드라이버의 함정입니다. 실제로 이는 큰 영향을 미치지 않을 것으로 보입니다: GPU가 전원이 켜져 있을 때 FLUSH_ID에 대한 쓰기는 무시되는 것으로 보이며; GPU가 전원이 꺼져 있을 때, 드라이버가 제공하는 dummy_latest_flush 페이지는 의도적으로 플러시를 수행하지 않도록 설계되었으므로, dummy_latest_flush에 쓰는 유일한 효과는 *더 많은* 플러시가 발생하게 만드는 것입니다.
2. panthor_device_mmap_io()는 MAP_PRIVATE 매핑(VM_SHARED 플래그가 없는 매핑)을 차단하지 않습니다. VM_MAYWRITE와 함께 사용되는 MAP_PRIVATE는 VMA가 copy-on-write(쓰기 시 복사) 세맨틱스를 가짐을 나타내며, 이는 VM_PFNMAP의 경우 반쯤 지원되지만 상당히 위험한(cursed) 상태입니다. 특히, 이러한 매핑에서는 드라이버가 mmap() 동안 remap_pfn_range()를 호출하여 PTE를 설치할 수 있는 유일한 방법입니다(remap_pfn_range()는 **매핑된 물리 메모리의 물리 주소를 VMA의 vm_pgoff에 저장**하기를 원하기 때문입니다); panthor가 수행하듯이 나중에 폴트 핸들러를 통해 PTE를 설치하는 것은 프라이빗 매핑에서 지원되지 않으며, 따라서 이러한 매핑에서 폴트를 발생시키려 하면 vmf_insert_pfn_prot()가 BUG() 체크를 만나면서 충돌(splats)합니다.
VM_MAYWRITE 플래그를 지우고(FLUSH_ID에 대한 사용자 공간 쓰기는 의미가 없음) VM_SHARED를 요구함으로써(FLUSH_ID에 대한 copy-on-write 세맨틱스는 의미가 없음) 이를 수정합니다.
두 시나리오에 대한 재현 코드는 메일링 리스트의 내 패치 노트에 있습니다; 저는 Rock 5B 머신에서 이러한 버그가 존재하는 것을 테스트했습니다.
참고로, 저는 패치를 컴파일 테스트만 했지 실제 테스트는 해보지 않았습니다. 테스트 머신에 대한 작동하는 커널 빌드 설정이 아직 없기 때문입니다. 적용하기 전에 테스트해 주시기 바랍니다.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.