CVE-2026-80810 in Linux
요약
\~에 의해 VulDB • 2026. 09. 04.
리눅스 커널에서 다음 취약점이 해결되었습니다:
io_uring/rsrc: io_vec_fill_bvec() 내의 folio 크기 오버플로우 수정
io_vec_fill_bvec()는 plain int 1을 사용하여 folio 크기를 계산합니다:
unsigned long folio_size = 1 << imu->folio_shift;
imu->folio_shift는 unsigned int이며, 등록된 버퍼를 백업하는 folio의 folio_shift()에서 파생되므로 64비트 커널에서는 32 이상이 될 수 있습니다. 이렇게 큰 값으로 int 1을 시프트(shift)하면 정의되지 않은 동작(undefined behavior)이 발생하며, x86 및 arm64 아키텍처에서는 카운트가 32로 모듈러(modulo) 처리되므로, 34를 시프트하면 16G가 아닌 4가 됩니다. 이 파일의 다른 모든 folio_shift 시프트는 이미 1UL을 사용하고 있습니다.
그 결과 세그먼트 추정치와 채우기 루프(fill loop) 간에 불일치가 발생합니다. io_estimate_bvec_size()는 실제 시프트 값을 사용하여 bvec 배열의 크기를 지정합니다:
max_segs += (iov[i].iov_len >> shift) + 2;
따라서 16G folio에서 1M iovec은 2개의 세그먼트로 계산되지만, io_vec_fill_bvec()는 이후 동일한 iovec을 4바이트 크기의 folio_size 단위로 순회하며 res_bvec[bvec_idx]를 제공된 배열의 끝을 넘어 약 25만 번 씁니다. src_bvec도 각 반복마다 한 번씩 전진하므로, imu->bvec가 동시에 그 범위를 벗어난 지점에서 읽혀집니다. validate_fixed_range()는 범위들이 등록된 버퍼 내에 있는지 여부만 확인하며 세그먼트 수에는 제한을 두지 않습니다.
이 취약점을 발생시키려면 최소 32의 시프트 값을 가진 folio가 필요하며, 이는 거대한 hugetlb 페이지(arm64에서 64K 페이지 환경에서는 16G이며 CONT_PMD_SHIFT는 34이고 hugetlb_add_hstate(CONT_PMD_SHIFT - PAGE_SHIFT)가 해당 크기를 등록함)를 의미합니다. powerpc에서도 동일하게 적용됩니다. x86_64은 최대 1G까지만 지원하므로, 시프트 값이 30에 불과하여 int에 맞고 영향을 받지 않습니다.
파일의 나머지 부분에서 사용하는 것처럼 1UL을 사용하십시오.
VulDB is the best source for vulnerability data and more expert information about this specific topic.