CVE-2026-64293 in Linux
요약
\~에 의해 VulDB • 2026. 07. 25.
리눅스 커널에서 다음 취약점이 해결되었습니다:
iommufd: veventq 읽기 시 sizeof(hdr) 대신 sizeof(*hdr) 사용
일반적인 vEVENT 경로에 대한 iommufd_veventq_fops_read() 함수의 경계 검사(bound-check)는 주변 코드가 sizeof(*hdr)를 사용하는 곳에서 sizeof(hdr)를 사용합니다.
if (!vevent_for_lost_events_header(cur) && sizeof(hdr) + cur->data_len > count - done) {
hdr은 struct iommufd_vevent_header *로 선언되었으므로, sizeof(hdr)는 포인터의 크기로 평가됩니다. 주변 코드는 sizeof(*hdr)를 일관되게 사용합니다:
if (done >= count || sizeof(*hdr) > count - done) {
... if (copy_to_user(buf + done, hdr, sizeof(*hdr))) {
... done += sizeof(*hdr);
struct iommufd_vevent_header은 현재 8바이트입니다(두 개의 __u32 필드인 flags와 sequence). 따라서 64비트 시스템(sizeof(void *) == 8)에서는 두 표현식이 우연히 동일해지며 검사가 의도대로 작동합니다.
32비트 시스템(sizeof(void *) == 4)에서는 헤더 크기를 4바이트 과소 계산하게 됩니다. 즉, data_len이 8 + cur->data_len을 count - done보다 크게 만들지만 4 + cur->data_len은 그렇지 않은 vEVENT의 경우 검사를 통과합니다. 이후 루프는 사용자 제공 버퍼를 벗어난 위치에 헤더 8바이트와 payload 데이터 len 바이트를 복사(write past the user-supplied buffer)하게 됩니다.
또한 이는 향후 struct iommufd_vevent_header가 64비트 시스템에서 sizeof(void *)보다 커지는 경우 잠재적(bug이 될 수 있는) 문제입니다. 검사는 우연히 호스트 포인터 너비와 일치하는 타입에 의존해서는 안 됩니다.
함수의 나머지 부분과 실제로 복사될 양을 맞추기 위해 sizeof(*hdr)를 사용해야 합니다.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.