CVE-2026-84286 dotyczy exllamav3_ext, natywnego rozszerzenia CUDA w ExLlamaV3. CERT/CC opisuje out-of-bounds memory access z niewystarczającej walidacji indeksów przy dispatchu kernela: crafted input prowadzi do CUDA illegal memory access, crashu i niestabilnego wykonania. To nie RCE i nie należy go tak przedstawiać. Najciekawszy materiał leży gdzie indziej: poprawka jest merged do repo, a CERT wskazuje dziesiątki downstream dependencies, które muszą przebudować artefakty. „Upstream fixed” nie oznacza „moja aplikacja fixed”.
K=0 → ujemny indeks; checkpoint-derived cbi indeksuje 24-elementową tablicę bez sprawdzenia zakresu → CUDA OOB access, DoS/instability.Unknown, CERT wskazuje 49 downstreamów do rebuildu — nie wymyślaj fixed version.Supply-chain problem mimo istniejącego fixu
Bo źródło, package i wdrożony binary to trzy różne obiekty. Możemy mieć jednocześnie: upstream main z poprawionym kodem, package index bez jednoznacznego nowego release, downstream pinujący wcześniejszy commit, kontener z wcześniej skompilowanym exllamav3_ext, wheel z natywnym binary sprzed fixu, application image, którego SBOM pokazuje nazwę biblioteki, ale nie commit/build provenance. To sytuacja, w której SCA oparte wyłącznie na semver bywa mało użyteczne. Attack path: aplikacja ładuje podatne rozszerzenie → mniej zaufany input dostarcza crafted checkpoint/input wpływający na parametry kernela → walidacja zakresu nie odrzuca wartości → kernel wykonuje OOB access → proces się wywraca. Exploitability zależy od tego, kto kontroluje model/checkpoint/input; offline inference na zamkniętym zbiorze ma inny profil niż publiczna usługa przyjmująca modele od użytkowników.
Co znaczy „fixed”?
Rozdziel: severity (DoS/instability, nie RCE), exploitability (reachability do ścieżki parsującej crafted input), asset context (inference worker obsługujący wielu klientów, GPU node, shared AI service = większy availability impact), supply-chain context (podatny binary może trafić przez downstream package/container nawet bez „ExLlamaV3” w manifestach). Ponieważ vendor status to Unknown, nie wymyślaj minimalnej fixed version — dopuść dowód na poziomie commit/build: source commit zawiera fix, native extension przebudowana po tym commicie, final wheel/container z tego buildu, deployment używa nowego binary. To dojrzalsze niż version >= X, gdy X nie istnieje w wiarygodnym źródle.
Remediation i weryfikacja
Dla bezpośrednich użytkowników: pobrać upstream z fixem/PR, przebudować rozszerzenie, przebudować wheel/container/image, redeployować workerów, usunąć/oznaczyć stare artefakty i cache. Dla downstream maintainers: propagacja fixu do własnego release. Weryfikacja: commit SHA źródła, CI build provenance/SLSA attestation, hash natywnego .so, SBOM powiązany z finalnym artefaktem, test regresyjny z wartościami brzegowymi K/cbi, redeploy confirmation. Sprawdź cache — nowy obraz nie pomoże, jeśli runtime ładuje stary native artifact z trwałego mountu. VEX ma tu wartość: jeśli aplikacja nie przyjmuje nieufnych checkpointów i używa zweryfikowanego zestawu modeli, opisz brak realnego attack path mimo obecności komponentu; jeśli przyjmuje zewnętrzne modele — priorytet rośnie.
Powiązane na blogu
- Axolotl: trust_remote_code — AI supply chain i nieufny model
- mistral.rs: image_url to nie tylko obraz — AI infra jako perimeter
Źródła
- CERT/CC VU#369611 — kb.cert.org
- Upstream fix (PR #310) — github.com
Nota redakcyjna: stan informacji 12 września 2026. CVE-2026-84286 (exllamav3_ext) to DoS przez CUDA OOB access, nie RCE. Fix merged w repo, vendor status Unknown, 49 downstreamów wymaga rebuildu. Artykuł zaleca śledzenie provenance source→build→deployment zamiast prostego version matchingu.