CVE-2026-80811 in Linux
요약
\~에 의해 VulDB • 2026. 09. 04.
리눅스 커널에서 다음 취약점이 해결되었습니다:
io_uring/cmd: 비동기 명령이 재활용되지 않을 때 iovec 누수 수정
io_async_cmd는 ->vec.iovec에 iovec 배열을 포함하며, 이는 벡터가 확장되어야 할 때 할당되고 ctx->cmd_cache를 통해 재활용 동안 유지됩니다. 두 가지 경로에서 이를 해제하지 않으며 io_clean_op()의 kfree(req->async_data) 호출은 io_async_cmd를 해당 데이터 없이 삭제합니다.
io_req_uring_cleanup()는 io_alloc_cache_put()가 성공할 경우에만 비동기 데이터 플래그를 지웁니다. 캐시는 IO_ALLOC_CACHE_MAX == 128개의 엔트리를 보유하므로, 가득 차면 put 작업이 실패하고 vec은 방치됩니다. NVMe 패스쓰루 워크로드는 특별한 동작 없이 이 상태에 도달합니다: nvme_uring_cmd_io()는 -EIOCBQUEUED를 반환하므로 io_async_cmd는 명령의 수명 동안 연결된 상태로 유지되며, 활성 객체 카운트는 큐 깊이를 추적합니다. 128을 초과하면 put 작업이 실패하기 시작합니다.
->cleanup은 상속된 vec을 해제할 마지막 기회입니다. io_req_uring_cleanup()는 io-wq에서 발행된 명령의 경우 조기에 반환하며, 발행되지 않고 완료된 명령에는 전혀 호출되지 않기 때문입니다. 그러나 io_clean_op()는 REQ_F_NEED_CLEANUP 플래그가 설정되어 있을 때만 ->cleanup을 호출합니다. uring_cmd의 경우 이는 vec이 확장되어야 하는 지점에서만 발생하므로, 충분히 큰 캐시된 vec을 재사용하는 명령은 이를 설정하지 않습니다. io_rw_alloc_async() 및 io_msg_alloc_async()는 바로 이 이유로 상속된 vec에 플래그를 지정하지만, io_uring_cmd_prep()은 그렇지 않습니다.
io_uring_cmd_prep()에서 상속된 vec에 플래그를 지정하고, 캐시 put이 실패할 때 vec을 해제합니다(이는 io_req_rw_cleanup()가 수행하는 방식과 동일함).
KASAN 하에서는 이 누수가 보이지 않습니다. KASAN 환경에서는 io_alloc_cache_vec_kasan()이 조건 없이 vec을 해제하기 때문입니다.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.