Katalog CVE

CVE-2026-80810

Nieznane
Opublikowano: Przetłumaczono: NVD NIST

Streszczenie

W jądrze Linux w podsystemie io_uring/rsrc wykryto podatność polegającą na przepełnieniu przy obliczaniu rozmiaru folio w funkcji io_vec_fill_bvec(). Użycie zwykłego int zamiast unsigned long przy przesunięciu bitowym może prowadzić do niezdefiniowanego zachowania dla folio o przesunięciu 32 lub więcej, co skutkuje zapisem poza granicami tablicy. Problem dotyczy głównie systemów z ogromnymi stronami hugetlb (np. 16G na arm64).

Ocena ryzyka

Podatność może prowadzić do uszkodzenia pamięci jądra, co może skutkować awarią systemu (panic) lub potencjalnie eskalacją uprawnień. Organizacje korzystające z io_uring i dużych stron hugetlb na architekturach 64-bitowych są narażone na niestabilność systemu.

Rekomendacja

Zaleca się natychmiastowe zastosowanie oficjalnej łatki z jądra Linux, która zmienia przesunięcie na 1UL. Należy również zaktualizować system do wersji jądra zawierającej poprawkę oraz monitorować biuletyny bezpieczeństwa dystrybucji.

Inne podatności w Linux kernel

Zobacz wszystkie
Oryginalny opis (angielski, źródło NVD)

In the Linux kernel, the following vulnerability has been resolved: io_uring/rsrc: fix folio size overflow in io_vec_fill_bvec() io_vec_fill_bvec() computes the folio size with a plain int 1: unsigned long folio_size = 1 << imu->folio_shift; imu->folio_shift is unsigned int and comes from folio_shift() of the folio backing the registered buffer, so it can be 32 or more on a 64 bit kernel. Shifting int 1 that far is undefined, and on x86 and arm64 the count is taken modulo 32, so a shift of 34 yields 4 rather than 16G. Every other folio_shift shift in this file already uses 1UL. The result is that the segment estimate and the fill loop disagree. io_estimate_bvec_size() sizes the bvec array with the real shift: max_segs += (iov[i].iov_len >> shift) + 2; so a 1M iovec on a 16G folio is charged 2 segments, while io_vec_fill_bvec() then walks the same iovec in folio_size chunks of 4 bytes and writes res_bvec[bvec_idx] a quarter of a million times, past the end of the array it was given. src_bvec is advanced once per iteration as well, so imu->bvec is read past its end at the same time. validate_fixed_range() only checks that the range is inside the registered buffer and does not bound the segment count. Reaching it needs a folio with a shift of at least 32, which means a gigantic hugetlb page: 16G on arm64 with 64K pages, where CONT_PMD_SHIFT is 34 and hugetlb_add_hstate(CONT_PMD_SHIFT - PAGE_SHIFT) registers that size, and likewise on powerpc. x86_64 tops out at 1G, so a shift of 30, which still fits in int and is unaffected. Use 1UL, as the rest of the file does.

Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS