
Preuves de concept et éléments de preuve pour deux découvertes concernant le pilote GPU Linux de NVIDIA, clôturées par le fournisseur comme un comportement attendu/prévu : la télémétrie des processus GPU inter-UID via NVML, et une faute MMU non privilégiée Xid 31 du moteur de copie via une course de démontage d'accès pair.
Code de preuve de concept et preuves brutes pour deux constats dans le pilote GPU Linux de NVIDIA, tous deux signalés via le VDP de NVIDIA et tous deux clôturés par NVIDIA comme comportement voulu/attendu. Publiés pour que le comportement soit documenté et reproductible ; aucun n'a de CVE et aucun ne sera corrigé.
| # | Constat | Classe | Issue du fournisseur | Répertoire |
|---|
| 1 | Télémétrie de processus GPU inter-UID via NVML | Divulgation d'informations (CWE-200 / CWE-862) | « comportement attendu » ; divulgation publique autorisée par écrit le 2026-08-20 | 01-nvml-cross-uid-telemetry/ |
| 2 | Défaut MMU du moteur de copie Xid 31 non privilégié via course de démontage P2P | Défaut GPU, non privilégié et déterministe | « comportement voulu et en tant que tel n'est pas un bug », clôturé le 2026-08-04 | 02-xid31-p2p-teardown-race/ |
Testé sur le pilote 595.71.05-open, A100-SXM4-80GB x4 (maillage complet NV4, sans NVSwitch, MIG désactivé), Ubuntu 24.04 / noyau 6.8.0, toolkit CUDA 12.9. Le constat 1 a également été reproduit sur 565.57.01-open.
Le constat 1 est une véritable exposition inter-UID. Le constat 2 est un défaut à impact non prouvé. Ils ne sont pas d'égale solidité et ne sont pas présentés comme tels.
Le constat 2 démontre qu'un utilisateur non privilégié peut provoquer de manière déterministe un défaut sur une paire de GPU NVLink
(5/5, attribué au PID, contre 4/4 témoins négatifs propres). Il ne démontre pas que le
défaut survit au processus déclencheur. Cette mesure n'a jamais été prise — le harnais réinitialisait le
GPU par réflexe avant le sondage, et le nœud a été déprovisionné avant qu'elle ne puisse être répétée. Deux
éléments de preuve indépendants plaident pour un auto-effacement du défaut : le catalogue Xid de NVIDIA classe
Xid 31 avec une action immédiate RESTART_APP, et le champ Recovery Action du GPU lui-même indiquait None
avant la réinitialisation. Tant que quelqu'un n'aura pas exécuté le canari post-arrêt dans
02-xid31-p2p-teardown-race/, traitez ceci comme un défaut à
rayon d'impact non prouvé, et non comme un déni de service.
Si vous avez une paire NVLink à disposition, cette seule expérience est la chose la plus précieuse que quiconque puisse contribuer ici. Cela prend quelques minutes.
git clone https://github.com/abhinavagarwal07/nvidia-gpu-security-poc
cd nvidia-gpu-security-poc
./capture_env.sh # enregistre les permissions des périphériques de votre hôte, le pilote, la topologie, les options /proc
# Constat 1 — nécessite un second utilisateur exécutant une charge de travail CUDA quelconque
(cd 01-nvml-cross-uid-telemetry/poc && make && ./nvml_harvest)
# Constat 2 — nécessite deux GPU connectés en NVLink. Provoque un défaut sur une paire de GPU. Ne pas exécuter sur du matériel partagé.
(cd 02-xid31-p2p-teardown-race/poc && ./build.sh && \
CUDA_VISIBLE_DEVICES=0,1 ./p2p_teardown_race_verbose --a 0 --p 1)
La sortie de capture_env.sh est ce qu'il faut joindre si vous signalez une différence avec nos résultats — elle
enregistre ls -l /dev/nvidia*, les entrées de mode de périphérique /proc/driver/nvidia/params, les options
de montage /proc (un montage hidepid= modifie ce que produit le constat 1), la topologie, le pilote et les versions
pynvml.
Le constat 2 provoque délibérément un défaut sur une paire de GPU. Il produit des entrées Xid 31 dans le journal du noyau et peut
nécessiter nvidia-smi --gpu-reset pour être effacé — et sur les systèmes NVLink/NVSwitch de génération Ampere,
NVIDIA documente que cette récupération dans le cas d'un lien tronc fatal est une opération à l'échelle du fabric, et non
d'un seul GPU. Exécutez-le uniquement sur du matériel que vous possédez ou pour lequel vous avez une autorisation écrite de perturbation, avec
aucun co-locataire. Tous les tests d'origine ont été effectués sur un nœud à locataire unique, contrôlé par un chercheur, sous
un bail de cluster autorisé.
Le constat 1 est en lecture seule et passif. Il lit la télémétrie que le pilote expose déjà à chaque utilisateur local ; il n'écrit rien et n'injecte rien.
results/ dans chaque répertoire contient les verdicts JSON d'origine évalués par machine par exécution, les lignes Xid
dmesg capturées, les témoins positifs et négatifs, l'audit des privilèges de l'observateur, et les captures
d'environnement du nœud de test. Les UUID de GPU, les numéros de série matériels et les IP de nœuds sont expurgés ; rien d'autre
n'a été modifié.
Publications Full Disclosure pour les deux constats, y compris la correspondance avec le fournisseur et les calendriers de divulgation : https://abhinavagarwal07.github.io
Code de la preuve de concept et documentation : voir LICENSE.