CVE-2026-80810 in Linux
Zusammenfassung
von VulDB • 04.09.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
io_uring/rsrc: Behebung des Integer-Überlaufs der Folio-Größe in io_vec_fill_bvec()
io_vec_fill_bvec() berechnet die Folio-Größe mit einer einfachen int 1:
unsigned long folio_size = 1 << imu->folio_shift;
imu->folio_shift ist ein unsigned int und stammt aus folio_shift() der das registrierte Puffer backingenden Folio, sodass es auf einem 64-Bit-Kernel den Wert 32 oder höher annehmen kann. Das Verschieben von int 1 um diesen Betrag ist undefiniert; bei x86 und arm64 wird die Anzahl modulo 32 berechnet, sodass ein Shift von 34 das Ergebnis 4 statt 16G ergibt. Jeder andere folio_shift-Shift in dieser Datei verwendet bereits 1UL.
Die Folge ist, dass die Segmentabschätzung und der Füll-Schlüssel nicht übereinstimmen. io_estimate_bvec_size() dimensioniert das bvec-Array mit dem tatsächlichen Shift:
max_segs += (iov[i].iov_len >> shift) + 2;
Somit wird ein 1M iovec auf einer 16G-Folio als 2 Segmente berechnet, während io_vec_fill_bvec() denselben iovec in Folio-Größen-Chunks von 4 Byte durchläuft und res_bvec[bvec_idx] eine Viertelmillion Mal überschreibt, über das Ende des zugewiesenen Arrays hinaus. src_bvec wird ebenfalls pro Iteration um einen Schritt erhöht, sodass imu->bvec gleichzeitig außerhalb seines Endes gelesen wird. validate_fixed_range() prüft lediglich, ob der Bereich innerhalb des registrierten Puffers liegt, beschränkt aber nicht die Segmentanzahl.
Das Erreichen dieser Stelle erfordert eine Folio mit einem Shift von mindestens 32, was einer gigantischen Hugetlb-Seite entspricht: 16G auf arm64 mit 64K-Seiten, wo CONT_PMD_SHIFT 34 beträgt und hugetlb_add_hstate(CONT_PMD_SHIFT - PAGE_SHIFT) diese Größe registriert; ebenso bei powerpc. x86_64 endet maximal bei 1G, sodass ein Shift von 30, der noch in int passt, nicht betroffen ist.
Verwenden Sie 1UL, wie es im Rest der Datei üblich ist.
If you want to get best quality of vulnerability data, you may have to visit VulDB.