CVSS 8.8, EPSS bardzo niski, a podatność łamie granicę guest–host: Linux vmclock pokazuje, dlaczego świeżego EPSS nie wolno czytać bez kontekstu

CVE-2026-80724 w sterowniku Linux vmclock (PTP) to podatność na granicy guest–host: funkcja vmclock_miscdev_mmap() odrzuca zapisywalne mapowania, ale zostawia ustawiony flag VM_MAYWRITE. Dzięki temu guest OS może najpierw zmapować stronę jądra tylko do odczytu, a potem przez mprotect() podnieść uprawnienia do zapisu danych timekeeping hosta, które powinny pozostać read-only — to naruszenie integralności współdzielonej strony ABI, a nie (bez dodatkowego dowodu) VM escape czy host RCE. CVSS 8.8 (AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H). A EPSS? Około 0,154%, 5. percentyl — bardzo nisko.

Co EPSS mówi, a czego nie

EPSS przewiduje prawdopodobieństwo obserwowanej eksploatacji CVE w najbliższym okresie. To użyteczny sygnał — ale odpowiada na jedno konkretne pytanie. Nie mówi, jak groźny jest skutek, jaką granicę zaufania łamie podatność ani jak krytyczne jest to dla Twojego środowiska. Dla świeżego CVE EPSS jest z natury niski: nie ma jeszcze publicznych exploitów, danych o wykorzystaniu, szumu. Niski EPSS „dzień po publikacji” mówi głównie „jeszcze nikt tego masowo nie atakuje”, a nie „to nieważne”.

Trust boundary bije predykcję

Tu kontekst jest decydujący: podatność łamie granicę guest–host (scope changed). W środowisku multi-tenant/wirtualizacji to jedna z najważniejszych granic, jakie w ogóle mamy — guest, który zapisuje dane hosta, podważa izolację, na której opiera się cały model. Deprioritetyzacja takiego CVE dlatego, że „EPSS 0,15%”, to podporządkowanie realnej, potwierdzonej trust boundary metryce, która akurat nie na to pytanie odpowiada.

Antywzorzec: ORDER BY epss DESC

Sortowanie backlogu wyłącznie po EPSS ma tę samą wadę, co sortowanie wyłącznie po CVSS: redukuje wielowymiarową decyzję do jednej liczby. Dla środowiska wirtualizacyjnego CVE łamiące izolację guest–host powinno trafić wysoko mimo niskiego EPSS. EPSS jest świetny jako jeden z wielu wejść (zwłaszcza do odróżniania „atakowane teraz” od „teoretyczne”), ale nie jako gate, który sam zdejmuje priorytet.

Jak połączyć EPSS z kontekstem

Warto myśleć warstwowo, jak w modelach typu SSVC: EPSS/KEV odpowiadają na „czy to jest/będzie eksploatowane?”, a asset/impact context na „co się stanie i gdzie to boli”. Dla vmclock: exploitation-observed = niska, ale technical impact = total, a trust boundary = krytyczna dla hostów wirtualizacyjnych. Wypadkowa to wysoki priorytet dla hostów z wieloma guestami, niższy dla systemów, gdzie sterownik nie jest używany albo nie ma modelu multi-tenant.

Co powinien zrobić Vulnerability Engineer?

1. Zidentyfikuj hosty wirtualizacyjne z podatnym sterownikiem vmclock/PTP i modelem multi-tenant.
2. Nie deprioritetyzuj po samym EPSS — dla granicy guest–host traktuj kontekst izolacji jako nadrzędny.
3. Priorytetyzuj hosty z wieloma/niezaufanymi guestami; tam scope-changed impact jest najgroźniejszy.
4. Zaktualizuj kernel do wersji z poprawką (wg dystrybucji/backportów), bo affected range bywa doprecyzowywany.
5. Używaj EPSS jako jednego z wejść (np. do kolejkowania „atakowane teraz”), nie jako bramki zdejmującej priorytet.

Wniosek

CVE-2026-80724 to dobry test dojrzałości procesu: czy niski EPSS na świeżym CVE zdejmuje priorytet automatycznie, czy ustępuje kontekstowi. Podatność łamie granicę guest–host — jedną z fundamentalnych w wirtualizacji — więc mimo EPSS ~0,15% zasługuje na wysoki priorytet tam, gdzie ta granica jest krytyczna. EPSS jest cenny, ale odpowiada na „czy to jest atakowane?”, nie na „jaką izolację to łamie?”. Pytanie brzmi nie „jaki jest EPSS?”, tylko: jaką trust boundary ta podatność przełamuje i jak bardzo zależymy od tej granicy w tym środowisku?

Powiązane na blogu

• KEV mówi: atakują. EPSS mówi: 0,356% — predykcja vs dowód, różne pytania
• Device Tree przy boot — kiedy CVSS opisuje skutek lepiej niż prawdopodobieństwo

Źródła

• GitHub Advisory — CVE-2026-80724 / GHSA-66mv-wq2c-77c3 — github.com/advisories
• FIRST — EPSS (model i interpretacja) — first.org/epss

Nota redakcyjna: stan informacji 30 sierpnia 2026. CVE-2026-80724 (CVSS 8.8, scope changed) dotyczy sterownika Linux vmclock: vmclock_miscdev_mmap() pozostawia VM_MAYWRITE, umożliwiając guestowi zapis danych timekeeping hosta przez mprotect(). GitHub Advisory pokazuje EPSS ~0,154% (5. percentyl). Problem w drivers/ptp/ptp_vmclock.c, wprowadzony w Linux 6.13, naprawiony w 6.18.47, 7.1.11 i 7.2.1 (plus backporty vendorów; weryfikuj wg dystrybucji). Potwierdzonym skutkiem jest utrata read-only invariant dla host-written timekeeping page (sequence counter, UTC, TSC offset) — artykuł świadomie nie utożsamia tego z VM escape ani host RCE.