Avancement — mené sur quatre lignes : investigation (informations publiques) · investigation (patch/diff) · analyse (reproduction/démonstration) · rapport (synthèse d'apprentissage). Les quatre lignes sont terminées.

Ce qui a été confirmé

• Identifiant et statut CVE (publique), CNA (Chrome/Google), produit affecté (Google Chrome), composant affecté (Dawn).
• Version corrigée 150.0.7871.47 et commit de correctif (Dawn 43055cbe…), 3 fichiers modifiés et raisons des modifications.
• La révision vulnérable ne comporte aucune validation des contraintes de la spécification, ni forçage, ni test de régression ; la révision corrigée les comporte tous — confirmé par comparaison statique des deux instantanés Dawn réellement épinglés par Chrome (cases/20260804-cve-2026-13934-4d10a8/report.md §3).

Non encore confirmé (non comblé par des suppositions)

• Aucune observation au niveau de l'exécution — les deux révisions n'ont pas été compilées pour exécuter les tests unitaires. La sortie réelle des messages d'erreur de validation, les paramètres VkSampler générés et les rapports VUID de la couche de validation Vulkan sont des valeurs attendues fondées sur des preuves tirées du code (cases/…-4d10a8/report.md §4).
• Plateformes affectées — la description de la CVE indique « on Android », mais l'avis du fournisseur qui porte cette CVE est un avis du canal desktop. La validité du même chemin sur desktop n'a pas été vérifiée.
• Bornes des versions affectées — les tags Chromium 150.0.7871.46·.47·.63 épinglent tous la même révision Dawn, mais la CVE indique « prior to .47 ». La justification de cette notation n'a pas pu être confirmée.
• Complétude du correctif — un seul commit côté Dawn référençait ce bug, mais la présence de modifications d'accompagnement côté Chromium src n'a pas fait l'objet d'une enquête exhaustive.
• Analyse interne du fournisseur — l'issue Chromium 513006636 contenant la cause est en accès restreint.

Sévérité — varie selon les sources. La note propre du fournisseur (Chromium) est Medium, le CVSS v3.1 de CISA-ADP est 9.6 CRITICAL (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H) et il n'existe aucune évaluation propre de NVD. Les deux sont présentées sans trancher laquelle est correcte — l'interprétation se trouve dans docs/cve-2026-13934/overview.md.

Ce dépôt ne contient aucun service déployé (API, backend, base de données, etc.). Tous les livrables sont des documents.

Conclusions principales

1. Cause — le prérequis exigé par la spécification n'était pas vérifié

La spécification Vulkan exige que les samplers avec conversion YCbCr aient le mode d'adresse de tous les axes défini sur CLAMP_TO_EDGE et le filtrage anisotrope (anisotropy) désactivé (VUID-VkSamplerCreateInfo-addressModeU-01646). Avant le patch, Dawn ne vérifiait pas cette contrainte, de sorte que des paramètres non conformes à la spécification pouvaient passer la validation et atteindre la création de VkSampler.

Le point décisif est le modèle de menace. La description publique suppose un attaquant ayant déjà compromis le processus de rendu (« a remote attacker who had compromised the renderer process »). Depuis cette position, on peut manipuler directement les commandes inter-processus plutôt que les chemins d'API web normaux ; la validation côté rendu est donc hors de la frontière de confiance. Et le backend Vulkan de Dawn s'exécute dans le processus GPU, plus privilégié que le rendu — c'est pourquoi cette faille constitue une surface d'évasion de la sandbox.

Base : cases/20260804-cve-2026-13934-4d10a8/root_cause.md §2 · Détails : docs/cve-2026-13934/root-cause-and-fix.md

2. Correctif — ne s'est pas arrêté à une seule couche de validation

Le commit de correctif est Dawn 43055cbeadddca41a9c973a809f859d641077b2f (« Add YCbCr sampler validation », 2026-05-27, Bug: 513006636) et modifie trois fichiers.

Cette structure est le cœur de cette CVE. Puisqu'on suppose le rendu déjà compromis, la validation seule ne suffit pas ; la deuxième couche, qui force les valeurs du côté le plus privilégié, constitue la véritable ligne de blocage. Résumer cela par « la validation d'entrée manquait, on a donc ajouté la validation » manque l'essentiel de la conception défensive.

L'ampleur des modifications est de 53 lignes ajoutées, 0 ligne supprimée — un patch qui comble les vérifications manquantes sans modifier la logique existante.

Base : research/20260804-cve-2026-13934-diff-92f928/report.md §3·§4 · cases/20260804-cve-2026-13934-4d10a8/patch_diff.md §4

3. Démonstration — confirmée jusqu'au niveau statique

Le code source des deux instantanés Dawn réellement épinglés par Chrome a été comparé.

Ce qui ressort ici : le côté vulnérable possédait déjà une branche YCbCr et 2 vérifications. La faille n'était pas un chemin manquant, mais l'absence de vérifications de contraintes conditionnelles dans la branche.

Aucune compilation ni exécution n'ayant été effectuée, les deux éléments ci-dessous sont des valeurs attendues fondées sur le code, et non des mesures.

Base : cases/20260804-cve-2026-13934-4d10a8/report.md §1~§4 · Détails : docs/cve-2026-13934/evidence.md

4. Enseignements

Du point de vue de la conception de sécurité

• Les valeurs qui franchissent une frontière de confiance doivent être retraitées du côté qui les reçoit. La validation côté client/rendu sert au confort et au diagnostic ; à l'intérieur de la frontière de privilèges, les valeurs doivent être validées ou forcées.
• Un « prérequis exigé par la spécification » n'est pas respecté s'il n'est pas imposé dans le code. Les contraintes conditionnelles doivent être traitées dans la branche où la condition est vérifiée ; dans ce cas, la branche existait et seules les vérifications manquaient.
• Le rejet (reject) et la correction (clamp) ont des rôles différents. Ce patch rejette sur les chemins normaux et applique une correction aux valeurs provenant de l'extérieur de la frontière de confiance.
• Ne pas juger sur une seule note de sévérité. La même vulnérabilité porte à la fois la note Medium du fournisseur et un CVSS 9.6 CRITICAL. C'est en lisant ensemble le prérequis (compromission préalable du rendu) qu'on voit le risque réel.
• Ne pas inverser le sens des signaux de détection. Les messages d'erreur de validation n'apparaissent qu'après le patch. Le raisonnement « aucune de ces erreurs dans les logs, donc nous sommes en sécurité » est à l'envers.

Du point de vue de la méthode d'investigation

• On peut retracer le correctif même sans patch dans les liens de référence de la CVE. Le commit de correctif a été trouvé en suivant : numéro de bug dans l'avis du fournisseur → tags de comparaison des versions → révision du composant dans DEPS → recherche du numéro de bug dans le journal des commits du composant. Procédure : research/20260804-cve-2026-13934-diff-92f928/sources.md §6.
• Les tests de régression constituent la meilleure spécification d'observation. Le test fourni avec le patch définit « quelle entrée produit quel résultat », ce qui permet de confirmer la différence avant/après sans reproduction dangereuse.
• Ne pas mélanger ce qui est confirmé et ce qui est estimé. Les livrables de ce dépôt ne laissent pas les éléments non confirmés en blanc ; ils les consignent comme « non confirmé + raison ».

Détails : docs/cve-2026-13934/lessons.md

Livrables

Documents d'apprentissage (docs/)

Investigation — informations publiques et périmètre d'impact (research/20260804-cve-2026-13934-6bacf7/)

Investigation — comparaison patch/diff (research/20260804-cve-2026-13934-diff-92f928/)

Analyse — reproduction/démonstration (pour l'apprentissage) (cases/20260804-cve-2026-13934-4d10a8/)

Rapports (reports/20260804-cve-2026-13934-8400bc/)

Sources primaires externes (résumé)

• CVE Record : https://www.cve.org/CVERecord?id=CVE-2026-13934
• NVD : https://nvd.nist.gov/vuln/detail/CVE-2026-13934
• Avis du fournisseur : Chrome Releases « Stable Channel Update for Desktop » (2026-06-30)
• Commit de correctif : https://dawn.googlesource.com/dawn/+/43055cbeadddca41a9c973a809f859d641077b2f

La liste complète, avec les dates de publication et les identifiants, se trouve dans les sources.md des deux lignes d'investigation.

Collecte périodique : research/topics/<topic>/

Règles (résumé)

• Committer uniquement du texte. Binaires, dumps et captures d'écran interdits. 1 fichier ≤ 1 MiB.
• Chemins autorisés : research/ · cases/ · work/ · reports/ · docs/ · .laurelin/ · .github/
• Les humains ne committent pas directement ; les instructions sont données dans le projet de travail Laurelin → Aulë committe.
• Conventions détaillées : docs/conventions.md