abhinavagarwal07/nvidia-gpu-security-poc
PoC ed evidenze per due risultati relativi al driver GPU Linux NVIDIA chiusi dal vendor come comportamento previsto/intenzionale: telemetria dei processi GPU cross-UID tramite NVML e un fault MMU del copy-engine Xid 31 non privilegiato tramite una race condition di teardown dell'accesso peer.
Codice proof-of-concept ed evidenze grezze per due segnalazioni nel driver GPU Linux di NVIDIA, entrambe riportate tramite il VDP di NVIDIA e chiuse da NVIDIA come comportamento previsto/atteso. Pubblicate affinché il comportamento sia documentato e riproducibile; nessuna delle due ha un CVE e nessuna verrà corretta.
| # | Segnalazione | Classe | Esito del fornitore | Directory |
|---|
| 1 | Telemetria di processo GPU cross-UID tramite NVML | Divulgazione di informazioni (CWE-200 / CWE-862) | "comportamento previsto"; divulgazione pubblica autorizzata per iscritto il 2026-08-20 | 01-nvml-cross-uid-telemetry/ |
| 2 | Fault MMU del copy-engine Xid 31 non privilegiato tramite race di teardown P2P | Fault GPU, non privilegiato e deterministico | "comportamento previsto e pertanto non un bug", chiusa il 2026-08-04 | 02-xid31-p2p-teardown-race/ |
Testato sul driver 595.71.05-open, A100-SXM4-80GB x4 (NV4 full mesh, senza NVSwitch, MIG disattivato), Ubuntu 24.04 / kernel 6.8.0, CUDA toolkit 12.9. La segnalazione 1 è stata riprodotta anche su 565.57.01-open.
La segnalazione 1 è una reale esposizione cross-UID. La segnalazione 2 è un fault con impatto non dimostrato. Non sono ugualmente forti e non vengono presentate come tali.
La segnalazione 2 dimostra che un utente non privilegiato può causare deterministicamente un fault su una coppia di GPU NVLink
(5/5, attribuito al PID, contro 4/4 controlli negativi puliti). Non dimostra che il fault sopravviva al processo che lo ha innescato. Quella misurazione non è mai stata effettuata — l'harness ha resettato la GPU in modo riflessivo prima del probing, e il nodo è stato deprovisionato prima che potesse essere ripetuta. Due
elementi di evidenza indipendenti suggeriscono che il fault si auto-risolve: il catalogo Xid di NVIDIA classifica
Xid 31 con azione immediata RESTART_APP, e il campo Recovery Action della GPU stessa riportava None
prima del reset. Finché qualcuno non esegue il canary post-kill in
02-xid31-p2p-teardown-race/, tratta questa come un fault con
raggio d'esplosione non dimostrato, non come un denial of service.
Se hai una coppia NVLink da dedicare, quell'esperimento è la cosa di maggior valore che chiunque possa contribuire qui. Richiede pochi minuti.
git clone https://github.com/abhinavagarwal07/nvidia-gpu-security-poc
cd nvidia-gpu-security-poc
./capture_env.sh # registra permessi device del tuo host, driver, topologia, opzioni /proc
# Segnalazione 1 — richiede un secondo utente che esegua un qualsiasi workload CUDA
(cd 01-nvml-cross-uid-telemetry/poc && make && ./nvml_harvest)
# Segnalazione 2 — richiede due GPU connesse via NVLink. Causa un fault su una coppia di GPU. Non eseguire su hardware condiviso.
(cd 02-xid31-p2p-teardown-race/poc && ./build.sh && \
CUDA_VISIBLE_DEVICES=0,1 ./p2p_teardown_race_verbose --a 0 --p 1)
L'output di capture_env.sh è ciò che devi allegare se segnali una differenza rispetto ai nostri risultati — registra
ls -l /dev/nvidia*, le voci device-mode in /proc/driver/nvidia/params, le opzioni di mount di /proc
(un mount hidepid= cambia ciò che produce la segnalazione 1), topologia, driver e versioni di pynvml.
La segnalazione 2 causa deliberatamente un fault su una coppia di GPU. Produce voci Xid 31 nel log del kernel e potrebbe
richiedere nvidia-smi --gpu-reset per essere risolto — e sui sistemi NVLink/NVSwitch di generazione Ampere
NVIDIA documenta che il ripristino nel caso di trunk-link fatale è un'operazione a livello di fabric, non
di singola GPU. Eseguilo solo su hardware di tua proprietà o per il quale hai autorizzazione scritta a interromperlo, con
nessun co-tenant. Tutti i test originali sono stati effettuati su un nodo single-tenant controllato dal ricercatore sotto
una lease cluster autorizzata.
La segnalazione 1 è read-only e passiva. Legge telemetria che il driver espone già a ogni utente locale; non scrive nulla e non inietta nulla.
results/ in ogni directory contiene i JSON di verdetto per-esecuzione valutati dalla macchina, le righe Xid
catturate da dmesg, controlli positivi e negativi, l'audit dei privilegi dell'osservatore e le catture
dell'ambiente dal nodo di test. Gli UUID delle GPU, i seriali hardware e gli IP dei nodi sono oscurati; nient'altro
è stato modificato.
Post di Full Disclosure per entrambe le segnalazioni, inclusa la corrispondenza con il fornitore e le timeline di divulgazione: https://abhinavagarwal07.github.io
Codice PoC e documentazione: vedi LICENSE.