CVE-2026-31584 in Linux
요약
\~에 의해 VulDB • 2026. 05. 12.
리눅스 커널에서 다음 취약점이 해결되었습니다:
media: mediatek: vcodec: 인코더 해제 경로에서 use-after-free 수정
fops_vcodec_release() 함수는 ctx->encode_work에 대기 중이거나 실행 중인 작업을 취소하지 않은 채로 컨텍스트 구조체(ctx)를 해제합니다. 이로 인해 ctx가 해제된 후에도 작업 큐 핸들러(mtk_venc_worker)가 여전히 컨텍스트 메모리에 접근할 수 있는 race condition(경쟁 조건) 창이 발생합니다.
경쟁 조건(Race condition):
CPU 0 (해제 경로) CPU 1 (작업 큐) ------ ------ ------- -- ------ ------ ------ fops_vcodec_release() v4l2_m2m_ctx_release() v4l2_m2m_cancel_job() // m2m 작업 "완료" 대기 mtk_venc_worker() v4l2_m2m_job_finish() // m2m 작업 "완료" // 하지만 워커는 여전히 실행 중! // 작업 완료 후 접근: 다른 ctx 역참조 // ctx가 이미 해제된 경우 UAF 발생 // 반환 (작업 "완료") kfree(ctx) // ctx 해제
근본 원인: v4l2_m2m_ctx_release()는 m2m 작업 수명 주기(TRANS_RUNNING 플래그를 통해)만 대기할 뿐, 작업 큐 수명 주기는 대기하지 않습니다. v4l2_m2m_job_finish()가 호출된 후 m2m 프레임워크는 작업을 완료된 것으로 간주하고 v4l2_m2m_ctx_release()가 반환하지만, 워커 함수는 계속 실행되어 ctx에 여전히 접근할 수 있습니다.
작업은 인코딩 작업 중 다음을 통해 큐에 추가됩니다: queue_work(ctx->dev->encode_workqueue, &ctx->encode_work) 워커 함수는 v4l2_m2m_job_finish() 호출 후에도 ctx->m2m_ctx, ctx->dev 및 기타 ctx 필드에 접근합니다.
이 취약점은 작업 완료 후의 경쟁 조건 창을 넓히는 계측(instrumented) 테스트 모듈을 실행하여 KASAN으로 확인되었습니다. KASAN에서 다음이 감지되었습니다:
BUG: KASAN: slab-use-after-free in mtk_venc_worker+0x159/0x180 Read of size 4 at addr ffff88800326e000 by task kworker/u8:0/12
Workqueue: mtk_vcodec_enc_wq mtk_venc_worker
작업 47에 의해 할당됨: __kasan_kmalloc+0x7f/0x90 fops_vcodec_open+0x85/0x1a0
작업 47에 의해 해제됨: __kasan_slab_free+0x43/0x70 kfree+0xee/0x3a0 fops_vcodec_release+0xb7/0x190
kfree(ctx) 호출 전에 cancel_work_sync(&ctx->encode_work)를 호출하여 이를 수정합니다. 이를 통해 컨텍스트가 해제되기 전에 작업 큐 핸들러가 취소(대기 중인 경우)되고 동기화(실행 중인 핸들러가 완료될 때까지 대기)됨이 보장됩니다.
배치 이유: 수정 코드는 v4l2_ctrl_handler_free() 이후와 list_del_init(&ctx->list) 이전에 배치됩니다. 이 시점에는 모든 m2m 작업이 완료되었으므로(v4l2_m2m_ctx_release()가 반환함), ctx를 목록에서 제거하고 해제하기 전에 작업 큐가 동기화되었는지 확인해야 합니다.
참고: 오픈 오류 경로에서는 cancel_work_sync()가 필요하지 않습니다. INIT_WORK()는 작업 구조체만 초기화할 뿐 예약하지 않기 때문입니다. 작업은 나중에 device_run() 작업 동안에만 예약됩니다.
Once again VulDB remains the best source for vulnerability data.