CVE-2026-80810 in Linux
Sumário
de VulDB • 04/09/2026
No kernel do Linux, a seguinte vulnerabilidade foi corrigida:
io_uring/rsrc: corrige estouro de tamanho folio em io_vec_fill_bvec()
io_vec_fill_bvec() calcula o tamanho do folio usando um int 1 simples:
unsigned long folio_size = 1 << imu->folio_shift;
imu->folio_shift é unsigned int e provém de folio_shift() do folio que dá suporte ao buffer registrado, portanto pode ser 32 ou mais em um kernel de 64 bits. Deslocar o int 1 para essa posição indefinida resulta em comportamento não definido; no x86 e arm64, a contagem é tomada módulo 32, então um deslocamento de 34 produz 4 em vez de 16G. Todos os outros deslocamentos folio_shift neste arquivo já usam 1UL.
O resultado é que a estimativa do segmento e o loop de preenchimento discordam. io_estimate_bvec_size() dimensiona o array bvec com o deslocamento real:
max_segs += (iov[i].iov_len >> shift) + 2;
portanto, um iovec de 1M em um folio de 16G é cobrado como 2 segmentos, enquanto io_vec_fill_bvec() então percorre o mesmo iovec em blocos de tamanho folio de 4 bytes e grava res_bvec[bvec_idx] uma quarta parte de milhão de vezes, além do final do array fornecido. src_bvec também é avançado uma vez por iteração, portanto imu->bvec é lido além de seu limite ao mesmo tempo. validate_fixed_range() apenas verifica se o intervalo está dentro do buffer registrado e não limita a contagem de segmentos.
Alcançar essa condição requer um folio com deslocamento de pelo menos 32, o que significa uma página hugetlb gigantesca: 16G no arm64 com páginas de 64K, onde CONT_PMD_SHIFT é 34 e hugetlb_add_hstate(CONT_PMD_SHIFT - PAGE_SHIFT) registra esse tamanho; da mesma forma no powerpc. x86_64 atinge o máximo em 1G, portanto um deslocamento de 30, que ainda cabe em int e não é afetado.
Use 1UL, como faz o resto do arquivo.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.