Linux DRM Ioctl Developed By AMD Being Disabled Following Ongoing Security Issue

Red Hat의 David Airlie는 금요일 Linux 7.1을 위한 DRM 수정 사항의 풀 리퀘스트 (pull request)에서 다음과 같이 작성했습니다:

"매주 DRM 수정 사항이 올라오고 있지만, 불행히도 상황이 안정되는 데 기여하지 못하고 있습니다. 다양한 경계 검사 (bounds checks), 누수 (leaks) 및 UAF (Use-After-Free) 유형의 문제들에 대한 많은 드라이버 수정 사항이 포함되어 있습니다. i915/xe가 아마도 가장 정상적일 것이며, amdgpu는 곳곳에 수정 사항이 섞여 있고, ethosu에는 많은 작은 수정 사항들이 있습니다.

비공개로 문제를 수정하는 방식의 문제는 change handle ioctl 문제로 인해 우리에게 큰 타격을 주었습니다. "Sima가 옳았다"는 말처럼, 우리는 해당 ioctl을 비활성화했어야 했습니다. 이 기능은 불과 몇 개의 커널 전부터 도입되었으나 테스트를 제때 업스트림 (upstream)하는 데 실패했기 때문입니다. 여기 제시된 패치는 Sima가 식별한 문제들을 수정하지만, 알려진 문제 목록을 포함하여 해당 ioctl을 비활성화하며, 적절한 테스트가 작성되어 업스트림되기를 요청하고 있습니다. 이는 AMD ROCm과 함께 CRIU (Checkpoint and Restore in User-Space)를 위해 설계된 니치 (niche) 사용자 ioctl이므로, 그냥 비활성화하는 것이 괜찮다고 생각합니다.

이번 주에는 상황이 좀 진정되기를 바랍니다.

Dave."

Linux 7.1을 위해 계속해서 유입되는 과잉된 Linux 수정 사항 외에도, ioctl 관련 논란이 또 다른 문제입니다... 이는 GEM 핸들을 재할당하기 위한 DRM PRIME 인터페이스인 drm_gem_change_handle_ioctl()과 관련이 있습니다. 이 인터페이스는 AMD 엔지니어들이 그들의 CRIU (Checkpoint and Restore in User-Space) 이니셔티브의 일환으로 추진한 것입니다. CRIU는 특정 GEM 핸들을 가진 버퍼 객체 (buffer object)를 생성하거나 가져올 수 있어야 합니다. 이 인터페이스는 작년에 AMD 엔지니어들에 의해 고안되었습니다.

이 작업은 AMD가 ROCm 컴퓨팅 워크로드의 실행 중인 앱/컨테이너를 동결하고, 라이브 마이그레이션 (live migration) 또는 스냅샷 (snapshotting) 목적으로 나중에 복구할 수 있도록 상태를 저장할 수 있게 하기 위해 수행되었습니다.

올해 초 CVE-2026-23149와 함께, 사용자 공간 (user-space)에서 이를 사용하여 커널 경고 (kernel warnings)를 트리거할 수 있는 보안 취약점이 식별되었습니다. 이는 1월에 수정 시도가 있었으나 계획대로 진행되지 않았습니다.

보안 문제의 특성상 메일링 리스트 외부에서 논의가 이루어졌던 것과 달리, Simona Vetter는 이제 네 번째로 해당 인터페이스를 수정하려고 시도했으며, 결국 당분간은 이를 비활성화하기로 했습니다. Vetter는 이번 주 Linux 7.1을 위해 대기 중인 패치에서 다음과 같이 설명했습니다:

"이미 비밀이 탄로 났고, 우리가 사적으로 이 문제를 해결할 만큼 충분히 능숙하지 않다는 것이 명백해졌기에 리스트에 공개합니다. 지금까지의 경위는 다음과 같습니다:

5e28b7b9 ("drm: change_handle 내 prime swap 전 이전 핸들을 NULL로 설정")는 gem_close와 gem_change_handle ioctl 사이의 레이스 컨디션 (race condition)을 수정하려고 시도했으나, 몇 가지 잘못된 부분이 있었습니다:

• 로컬 변수 handle이 실제로는 새로운 핸들 (new handle)임에도 불구하고 혼동이 발생하여, 2단계 트릭 (two-stage trick)이 잘못된 idr 슬롯에 적용되었습니다. 7164d785 ("drm/gem: change_handle과 handle_delete 사이의 레이스 수정")는 또 다른 코드 블록을 추가하여 이를 수정하려 했으나, 에러 핸들링 (error handling)을 추가하는 것을 잊었습니다. 이는 결과적으로 두 가지 경로가 모두 다소 잘못된 상태로 남게 되었음을 의미합니다.

• dc366607 ("drm: 이전 포인터를 새로운 idr로 교체")는 또 다른 수정을 적용하려 했으나, 역시 핸들 혼동 문제로 인해 일관되지 못했습니다.

• 만약 우리가 새로운 핸들에 대해 2단계 접근 방식 (two-stage approach)을 사용했다면 이것이 올바른 수정 방식이었을 것입니다 (어느 정도, 어느 정도는 그렇지만, 현재 상황은 엉망입니다). 하지만 그것은 원래 수정의 의도가 아니었습니다.

또한 우리는 원래의 ioctl에 대해 병합된 igt가 없었는데, 이는 매우 심각한 문제입니다. 원래의 버그 수정 단계에서 이를 리스트 외부에서 해결하려 시도했고, AMD QA 인력들은 이제 버그가 수정되었다고 주장했습니다. 하지만 분명히 그렇지 않습니다. 이를 정리하기 위한 저의 시도는 다음과 같습니다:

• 로컬 변수의 이름을 new_handle로 변경합니다. args->handle과 별칭 (aliasing)을 사용하는 것은 너무 위험할 정도로 혼란스럽습니다.

• gem 객체 조회 (gem obj lookup)를 2단계 idr_replace와 병합하여, 그 과정에서 혼동을 피하도록 합니다."

• 이는 더 이상 여분의 임시 참조(surplus temporary reference)가 없으며, 오직 idr로부터 상속된 참조만 존재함을 의미합니다. new_handle에 대한 동시적인 gem_close가 이를 가로챌 수 있습니다. create_tail이 사용하는 것과 동일한 2단계 접근 방식을 사용하여 이를 수정합니다. 주석에 명시된 대로 이는 다소 과한 조치(overkill)일 수 있지만, 저 또한 이 모든 것을 정확하게 이해할 수 있다는 확신이 없으므로, 최대한의 편집증적(paranoia)인 보안을 위해 다른 ioctl에서 확립된 패턴을 따르기로 했습니다.

• 에러 경로(error paths)를 조정했습니다. 어떤 핸들을 제거하는지, 그리고 어떤 핸들에 대해 idr_replace를 호출하여 객체를 다시 (재)설치하는지를 제외하면 에러 경로와 성공 경로가 동일하기 때문에, 이를 공통화하려고 시도했습니다. 하지만 이로 인해 가독성이 더 나빠졌기 때문에, 불행히도 전체 코드 흐름의 대칭성을 다소 가리게 되더라도 더 장황한(verbose) 버전을 그대로 유지했습니다.

• 이 작업을 하는 김에, 7개의 공백 들여쓰기를 1개의 탭으로 교체했습니다.

그리고 마지막으로, 저는 이제 제 능력을 전혀 신뢰할 수 없으므로:

• igt 상황이 해결되고, 온리스트(on-list)에서 모든 사항이 완전한 합의에 도달할 때까지 해당 ioctl을 비활성화합니다.

v2:

Sashiko는 제가 idr_replace의 에러 경로를 올바르게 처리하지 않았음을 발견했습니다. gem_handle_delete에서와 같이 IS_ERR_OR_NULL로 확인해야 합니다. 따라서 네, 이 작업은 끝없이 까다롭기 때문에 기존 경로를 1:1로 그대로 사용하는 것이 확실합니다.

따라서 현재 DRM GEM change handle ioctl은 적절한 테스트가 추가되고 다양한 값에 대한 적절한 처리가 보장될 때까지 보안상의 이유로 비활성화되었습니다.

적어도 AMD ROCm 컴퓨팅 워크로드를 위한 체크포인트/복구(checkpoint/restore)에 관심이 있는 사용자 외에는 큰 영향이 없을 것입니다.

이 ioctl 비활성화는 안정적인(stable) Linux 커널 버전으로의 백포트(back-porting)도 예정되어 있습니다. 정리되고 테스트된 코드를 통해 이 인터페이스가 곧 다시 활성화될 수 있기를 바랍니다.