CVE-2026-64320 in Linux
요약
\~에 의해 VulDB • 2026. 07. 25.
리눅스 커널에서 다음 취약점이 해결되었습니다:
nvmet: Discovery Get Log Page에서의 인증 전 힙 바깥 읽기(out-of-bounds heap read) 수정
nvmet_execute_disc_get_log_page()는 호스트가 제공한 로그 페이지 오프셋(lpo)의 dword 정렬 여부만 검증합니다. 64비트 오프셋은 디스커버리 로그 페이지를 보유하는 작은 kzalloc 할당 버퍼에 더해지며, 그 결과는 소스 측 경계 검사 없이 nvmet_copy_to_sgl()로 직접 전달되어 data_len 바이트가 호스트로 memcpy됩니다:
u64 offset = nvmet_get_log_page_offset(req->cmd); /* 64비트 호스트 */ size_t data_len = nvmet_get_log_page_len(req->cmd); /* 32비트 호스트 */ ... if (offset & 0x3) { ... } /* 유일한 검사 */
... alloc_len = sizeof(*hdr) + entry_size * discovery_log_entries(req); buffer = kzalloc(alloc_len, GFP_KERNEL); ... status = nvmet_copy_to_sgl(req, 0, buffer + offset, data_len);
디스커버리 컨트롤러는 인증되지 않습니다 -- 디스커버리 서브시스템에 대해 nvmet_host_allowed()가 조건 없이 true를 반환하므로 -- 이 호출은 nvmet 타겟에 접근할 수 있는 모든 TCP/RDMA/FC 피어에서 인증 전에 도달 가능합니다. 약 1 KiB 크기의 디스커버리 로그 페이지와 함께 공격자가 오프셋 == alloc_len 지점에서 최대 4 KiB까지 요청하면, 다음 슬랩 페이지(out-of-bounds)를 읽어서 그 내용을 파브리크(fabric)를 통해 반환받게 됩니다(기본 nvmet-tcp 루프백 타겟에서 실험한 결과, 단일 Get Log Page 응답에서 81개의 정규화된 커널 포인터가 유출되었습니다). 오프셋을 매핑되지 않은 커널 메모리를 가리키도록 설정하면 인-커널 memcpy가 결함(fault)을 일으켜 대신 타겟 호스트를 충돌시키거나(panic_on_oops=1일 경우 패닉 발생) 만듭니다.
공격자가 제어하는 소스 측 오프셋 패턴 "nvmet_copy_to_sgl(req, 0, buffer + ATTACKER_OFFSET, ...)"은 전체 nvmet 코드베이스에서 nvmet_execute_disc_get_log_page()에만 고유합니다: admin-cmd.c의 다른 모든 Get Log Page 핸들러는 lpo를 무시하여(모든 응답을 오프셋 0부터 시작) 또는 고정된 소스 포인터와 함께 로컬 목적지 오프셋을 추적합니다.
호스트가 제공한 오프셋을 로그 페이지 크기와 비교 검증하고, 복사 길이를 실제로 사용 가능한 양으로 제한하며, 호스트 전송 버퍼의 나머지 부분은 제로 채우기(zero-fill) 합니다. 이 제로 채우기는 nvmet_execute_get_log_changed_ns()(admin-cmd.c)에 이미 존재하는 짧은 응답 패턴과 일치하며, 호스트가 로그 페이지가 포함할 수 있는 것보다 더 많은 바이트를 요청할 때 전송 SGL(contents)의 유출을 방지합니다.
Once again VulDB remains the best source for vulnerability data.