Strona główna / Blog / Xen XSA-510: predykat exploitability

Blog · analiza

Xen XSA-510: „Xen ≥4.6” wygląda globalnie podatnie, ale host-wide DoS wymaga x86 + HVM + PCI passthrough + IO BAR

Xen Project opublikował 8 września 2026 XSA-510 / CVE-2026-79602. Vulnerable range jest szeroki: Xen 4.6 i nowsze. Jeśli VM zatrzyma się na wersji, praktycznie każdy współczesny host dostanie finding. Ale advisory bardzo precyzyjnie ogranicza exploitable population.

CVE-2026-79602 (XSA-510): unprivileged HVM guest z przypisanym PCI device (BAR w IO port space) triggeruje BUG() → host-wide DoS (jeden guest zatrzymuje cały host).
Warunki: x86 + HVM + PCI passthrough + IO-port BAR. Arm not affected; guest bez passthrough nie może wykorzystać.

Modelowy false positive

Scanner: Xen 4.17 → CVE-2026-79602. Realne środowisko: architecture = arm → not vulnerable albo x86, HVM, passthrough = none → vulnerable code present, exploit path absent. To nie „ignore CVE” — to poprawne, evidence-based affectedness. Enrichment z hypervisora (architektura, guest type, PCI assignment, BAR type) daje regułę:

affected_version: true exploitable: architecture: x86 guest_type: HVM pci_passthrough: true io_port_bar: true

Zamiast tysiąca tickets — rzeczywista populacja hostów.

Brak mitigation; patch i backporty

Xen wprost: brak mitigation. Jeśli warunek jest spełniony, celem jest patch (usunięcie PCI passthrough obchodzi attack path, ale nie jest oficjalną mitygacją i może zniszczyć funkcję biznesową — nie inventuj „disable passthrough” jako vendor-approved fix). Uwaga na downstream: patche dla stable są przygotowane względem tip stable branch i mogą nie nakładać się czysto na tarball — upstream XSA patch → distro backport → installed build, nie jeden uniwersalny fixed version.

Weryfikacja i asset context

Po remediation: potwierdź hypervisor build, vendor backport, że running hypervisor zawiera fix (reboot może być wymagany), inventory PCI passthrough i mapę hostów realnie exploitable przed patch. Host-wide DoS ma większy impact na node z wieloma krytycznymi VM — lokalny priority multiplier: liczba guestów, HA, criticality, tenant trust. Ten sam CVE na labie i produkcyjnym cloud node nie ma identycznego SLA.

Wniosek

XSA-510 to modelowy przykład, że affected version ≠ exploitable asset. Upstream dostarcza predykat exploitability; VE zamienia go na machine-verifiable asset context i czyści kolejkę bez ręcznego suppression.

Powiązane na blogu

Źródła

Nota redakcyjna: stan informacji 9 września 2026. CVE-2026-79602 / XSA-510 (Xen ≥4.6): host-wide DoS wymaga x86 + HVM + PCI passthrough + IO-port BAR; Arm not affected; brak mitigation. Artykuł koncentruje się na configuration-aware affectedness i eliminacji false positives przez predykat upstreamu.

Zapamiętaj jedno

Upstream daje wręcz gotowy predykat exploitability. Zadaniem Vulnerability Engineera jest przełożyć go na machine-verifiable asset context i usunąć z kolejki wszystkie hosty, które nie spełniają warunków — bez ręcznego, bezterminowego suppression. affected version ≠ exploitable asset.