NVIDIA schließt 114 Lücken in GPU-Treiber und vGPU: welche Version welchen Zweig absichert

NVIDIA hat am 30. September 2026 das Security Bulletin „GPU Display Driver – September 2026" veröffentlicht. Es listet 114 CVEs von CVE-2026-47489 bis CVE-2026-47604 für die Grafiktreiber unter Linux und Windows sowie für die vGPU-Software. Nach der Tabelle in NVIDIAs GitHub-Fassung sind 78 davon mit hoch bewertet und 36 mit mittel, der höchste Basiswert ist 7,8. heise hat am 1. Oktober darüber berichtet. Wer Linux-Server mit NVIDIA-Karten betreibt, braucht je nach Treiberzweig 615.71.09, 610.57.04, 595.91.07 oder 580.178.04.

Was im Bulletin steht

Fast alle Einträge beschreiben Fehler im Kernelmodus des Treibers, viele davon im Open-Source-Kernelmodul: Use-after-free, nicht erhaltene Speicherrechte beim DMA-Mapping, Schreibzugriffe auf schreibgeschützten Speicher. Als mögliche Folgen nennt NVIDIA meist Codeausführung, Rechteausweitung, Denial of Service, Informationsabfluss und Datenmanipulation. 112 der 114 CVEs haben den Angriffsvektor lokal, zwei setzen physischen Zugang voraus. 91 verlangen niedrige Rechte, 21 hohe, zwei gar keine (eigene Zählung aus der Vektorspalte des Bulletins).

Laut heise geht aus der Warnmeldung nicht hervor, dass die Lücken bereits ausgenutzt werden. Im CVE-Datensatz zu CVE-2026-47574 steht in der Bewertung der CISA „Exploitation: none". Die Einschränkung auf lokalen Zugriff ist auf einem GPU-Server ein schwacher Trost: Jeder Container, jeder Jupyter-Kernel und jedes Konto mit Zugriff auf /dev/nvidia* ist ein lokaler Nutzer im Sinne dieser Vektoren.

Kritisch oder hoch

heise schreibt, dass die Tabelle auf NVIDIAs Supportseite CVE-2026-47574 als kritisch einstuft, während der CVE-Datensatz hoch nennt. Die Lücke steckt im Virtual GPU Manager für Linux und ermöglicht laut Beschreibung eine fehlerhafte Übertragung von Ressourcen zwischen Sicherheitsbereichen. Die GitHub-Fassung des Bulletins und der CVE-Datensatz bei MITRE geben beide 7,8 und hoch an. Die Supportseite selbst antwortete uns am 3. Oktober mit HTTP 403, die Einstufung als kritisch können wir deshalb nur über heise belegen. Für die Planung ändert das wenig: Wer vGPU einsetzt, sollte CVE-2026-47574 so behandeln, als wäre sie kritisch.

heise zählt außerdem 16 Lücken in der vGPU-Software. Das deckt sich mit der Tabelle, wenn man nur die CVEs zählt, die ausschließlich vGPU-Manager oder Gasttreiber betreffen. Insgesamt tragen 54 CVEs eine Zeile für den Virtual GPU Manager.

Gefixte Versionen nach Zweig

Unter Linux betreffen 80 der 114 CVEs die Treiberzweige. Das Bulletin nennt für jeden Zweig alle Versionen vor dem gefixten Stand als betroffen:

Die Werte gelten für GeForce, RTX/Quadro und Tesla gleichermaßen, mit den in Klammern genannten Ausnahmen unter Windows. Laut den Hinweisen im Bulletin enthalten auch die über Hardwarehersteller verteilten Windows-Treiber 610.60, 596.71 und 582.67 die Korrekturen. Wer einen älteren Zweig ohne eigene Zeile nutzt, soll laut NVIDIA auf den neuesten Zweig wechseln.

vGPU: Host und Gast gehören zusammen

Für vGPU sind die Versionen 20.2 und 19.6 die gefixten Stände, betroffen ist alles bis einschließlich 20.1 und 19.5. Der Virtual GPU Manager kommt auf XenServer, VMware vSphere, RHEL KVM und Ubuntu als 595.91.04 (vGPU 20.2) oder 580.178.05 (vGPU 19.6), auf Azure Local und Windows Server als 596.84 oder 582.78. Die Gasttreiber in den VMs müssen mitziehen: unter Linux 595.91.07 oder 580.178.04, unter Windows 596.86 oder 582.78. Ein aktualisierter Host mit alten Gasttreibern schließt nur einen Teil der Lücken. Proxmox VE steht in der Liste der Hypervisoren nicht ausdrücklich.

Container bringen das Kernelmodul nicht mit

Auf Inferenz-Hosts laufen vLLM, llama.cpp oder Triton meist in Containern, und deren Images bringen CUDA-Laufzeit und Bibliotheken mit. Das Kernelmodul nvidia.ko lädt dagegen der Host, und alle Container teilen sich diesen Kernel. Das NVIDIA Container Toolkit setzt deshalb einen auf dem Host installierten Treiber voraus. Ein frisch gezogenes Image ändert an den hier behobenen Lücken nichts. Umgekehrt muss nach dem Treiberupdate geprüft werden, ob die Images noch zur Treiberversion passen. Welche CUDA-Version aktuelle Inferenz-Engines voraussetzen, steht in unserem Beitrag zu vLLM 0.30 und llama.cpp 0.5.

Der neue Treiber ist erst aktiv, wenn das alte Modul entladen ist. Solange ein Prozess die GPU hält, geht das nicht, und auf einem Host mit laufendem Modellserver heißt das in der Praxis: Dienste stoppen oder umleiten, neu starten, wieder hochfahren. Wer DKMS nutzt, bekommt das Modul beim Paketupdate für den laufenden Kernel neu gebaut. Wer ein selbst gebautes oder gepatchtes Modul einsetzt, muss es aus dem gefixten Quellstand neu bauen, ein bloßer Versionsvergleich sagt dann wenig. Am 3. Oktober sind außerdem sieben stabile Kernel erschienen, ein Kernelupdate und der Treiberwechsel passen in dasselbe Wartungsfenster.

Die Treiberversion liefert nvidia-smi --query-gpu=driver_version --format=csv,noheader. Die ersten drei Ziffern zeigen den Zweig, und der Vergleich mit der Tabelle sagt, ob der Host betroffen ist. Wie leicht eine Patch-Runde an einem einzigen Host hängen bleibt, haben wir in Patch-Runde: Ein Host stoppt die ganze Flotte beschrieben. Für GPU-Hosts lohnt deshalb ein eigenes, geplantes Fenster statt der nächtlichen Sammelrunde.

Stand bei uns

Unsere drei GPU-Inferenz-Hosts mit zusammen fünf RTX 5090 und einer RTX 4060 Ti melden laut nvidia-smi vom 3. Oktober 2026 alle die Version 610.57.04, also den ersten gefixten Stand im Zweig R610. Auf einem der Hosts läuft ein selbst gebautes Open-Kernel-Modul mit dieser Versionsnummer. Ob es die Korrekturen enthält, entscheidet der Quellstand, auf dem der Bau beruht.

Unsere Empfehlung: Treiberversion auf jedem GPU-Host auslesen, gegen die Tabelle halten und für alles unterhalb des gefixten Stands ein Fenster mit Neustart planen. vGPU-Umgebungen ziehen Manager und Gasttreiber gemeinsam auf 20.2 oder 19.6.

Weiterführende Quellen

• NVIDIA Security Bulletin 5861, GitHub-Fassung als Markdown: alle 114 CVEs, Bewertungen, betroffene und gefixte Versionen
• NVIDIA-Supportseite zum Bulletin 5861: Originalseite, am 3.10.2026 für automatisierte Abrufe gesperrt (HTTP 403)
• CVE-2026-47574 bei cve.org: Datensatz zur vGPU-Lücke mit Bewertung hoch
• CVE-2026-47574 als JSON bei MITRE: CVSS 7,8 und CISA-Einschätzung „Exploitation: none"
• heise: Treiber-Lücken gefährden Linux- und Windows-PCs mit Nvidia-GPU: Bericht vom 1.10.2026 mit Versionsliste und der Abweichung bei der Einstufung
• NVIDIA Container Toolkit, Installationsanleitung: Treiber auf dem Host als Voraussetzung
• LWN: Seven stable kernels for Saturday: Kernel-Releases vom 3.10.2026