CVE-2026-80723 w jądrze Linux to out-of-bounds write podczas przetwarzania Device Tree przy boot: fdt_scan_reserved_mem() zapisuje każdy dynamicznie umieszczony podwęzeł /reserved-memory do lokalnej tablicy o rozmiarze MAX_RESERVED_REGIONS; gdy Device Tree definiuje więcej regionów niż limit, funkcja pisze poza końcem tablicy. CVSS 8.4 (AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H). Wektor wygląda groźnie — PR:N, wysoki wpływ na CIA. Ale kluczowe pytanie brzmi: kto w Twoim środowisku kontroluje Device Tree używane podczas bootu?
fdt_scan_reserved_mem() — za dużo dynamicznych /reserved-memory → zapis poza MAX_RESERVED_REGIONS.CVSS opisuje skutek, nie realny attack path
CVSS świetnie mówi, „co się stanie, jeśli podatność zostanie wykorzystana” — tu: uszkodzenie pamięci przy najwyższym wpływie. PR:N znaczy „nie trzeba uprawnień w systemie”. Ale nie odpowiada na pytanie, które w tym przypadku decyduje o ryzyku: kto może dostarczyć złośliwe Device Tree do procesu bootu? To nie jest właściwość, którą CVSS koduje — a właśnie ona rozstrzyga, czy attack path w ogóle istnieje.
Kto kontroluje Device Tree? To zależy od modelu zaufania boot chainu
Device Tree opisuje sprzęt jądru na platformach embedded/ARM. Kto go dostarcza — i czy może go zmienić atakujący — zależy od architektury bootu:
- DT wbudowany/podpisany, dostarczany przez zaufany firmware/bootloader (secure boot, immutable): atakujący spoza fizycznego dostępu zwykle go nie kontroluje → attack path wąski.
- DT zapisywalny (partycja/plik konfigurowalny, nieweryfikowany) albo modyfikowalny przez proces o niższym zaufaniu: kontrola nad DT staje się realna → attack path szeroki.
- Scenariusze multi-tenant/provisioning, gdzie DT pochodzi z niezaufanego źródła (np. dostarczany klientowi obraz): trzeba założyć kontrolę atakującego.
Ten sam podatny kernel jest więc realnie eksploatowalny w jednym modelu bootu, a praktycznie nie w innym — mimo identycznej wersji.
Threat model bootu jako część findingu
Bez tego pola finding sprowadza się do „affected kernel, 8.4” — technicznie poprawnego, ale nie mówiącego, czy realnie jest się czym martwić na tej konkretnej platformie.
Nie znaczy „ignoruj”
Brak oczywistej kontroli atakującego nad DT obniża priorytet, ale nie znosi go do zera: modele zaufania bywają błędnie zakładane (ktoś „wie”, że DT jest podpisany, choć nie jest), a fizyczny/insider dostęp bywa realny w niektórych zastosowaniach embedded. Docelowo patch kernela zamyka OOB write niezależnie od modelu. Kontekst boot chainu rozstrzyga kolejność i pilność, nie to, czy w ogóle naprawiać.
Co powinien zrobić Vulnerability Engineer?
- Zawęź populację do platform, gdzie Device Tree realnie jest w grze (embedded/ARM), nie każdego x86 z tym kernelem.
- Dla każdej ustal źródło i zaufanie DT: podpisany firmware, zapisywalna partycja, provisioning z niezaufanego źródła.
- Priorytetyzuj platformy, gdzie atakujący (w tym insider/fizyczny w danym zastosowaniu) może zmodyfikować DT.
- Zaktualizuj kernel wg dystrybucji/vendora; dla platform o niskim ryzyku oznacz niższy priorytet z triggerem
boot_chain_change. - Zweryfikuj założenia o secure boot/podpisywaniu DT — nie przyjmuj ich na słowo.
Wniosek
CVE-2026-80723 to przypadek, w którym CVSS opisuje skutek lepiej niż prawdopodobieństwo ścieżki. PR:N i 8.4 mówią „groźne, jeśli osiągalne”, ale osiągalność zależy od tego, kto kontroluje Device Tree przy boot — a to właściwość modelu zaufania boot chainu, nie numeru wersji jądra. Dojrzały VE zawęża populację do platform, gdzie DT jest w grze, i przypisuje priorytet według tego, czy atakujący może je zmodyfikować. Pytanie brzmi nie „czy mamy podatny kernel?”, tylko: kto na tej platformie realnie kontroluje Device Tree używane podczas bootu?
Powiązane na blogu
- Kernel CVE, który żyje w userspace — affected kernel to nie cała ocena attack surface
- vmclock: niski EPSS, granica guest–host — kontekst ponad pojedynczą metryką
Źródła
- GitHub Advisory — CVE-2026-80723 / GHSA-m4gx-g2g6-vwmj — github.com/advisories
- CVE-2026-80723 — cve.org
Nota redakcyjna: stan informacji 30 sierpnia 2026. CVE-2026-80723 (CVSS 8.4, PR:N) to out-of-bounds write w fdt_scan_reserved_mem() przy przetwarzaniu Device Tree podczas bootu (przekroczenie MAX_RESERVED_REGIONS). Realny attack path wymaga kontroli nad Device Tree dostarczanym przy boot, co zależy od modelu zaufania boot chainu danej platformy. Oficjalny Linux CVE announcement (tytuł „of: reserved_mem: prevent OOB when too many dynamic regions are defined”) wskazuje wprowadzenie w 6.12.13/6.13 i naprawę w 6.12.103, 6.18.44, 7.1.8 oraz 7.2; GitHub Advisory pokazuje EPSS ~0,156%. Dla dystrybucji uwzględnij vendor backporty, nie tylko upstream version string.