Progress stages — carried out across four tracks: investigation (public information), investigation (patch/diff), analysis (reproduction/demonstration), and reporting (learning summary); all four tracks are complete.

What has been confirmed

• CVE identifier and status (public), CNA (Chrome/Google), affected product (Google Chrome), affected component (Dawn).
• Fixed version 150.0.7871.47, the fixing commit (Dawn 43055cbe…), and the 3 changed files with the reasons for the changes.
• The vulnerable revision has no specification-constraint validation, enforcement, or regression tests, while the fixed revision has all of them — confirmed by static comparison of the two Dawn snapshots actually pinned by Chrome (cases/20260804-cve-2026-13934-4d10a8/report.md §3).

What has not been confirmed yet (not filled in with speculation)

• No execution-level observation — we did not build the two revisions and run unit tests. The actual output of the validation error message, the generated VkSampler parameters, and the VUID reports from the Vulkan validation layers are expected values based on the code (cases/…-4d10a8/report.md §4).
• Affected platform — the CVE description says "on Android", but the vendor advisory carrying this CVE is a desktop channel advisory. Whether the same path holds on desktop was not verified.
• Affected version boundary — Chromium tags 150.0.7871.46, .47, and .63 all pin the same Dawn revision, yet the CVE says "prior to .47". We could not confirm the basis for this notation.
• Completeness of the fix — there was one commit on the Dawn side referencing this bug, but whether accompanying changes were made on the Chromium src side was not exhaustively investigated.
• Vendor internal analysis — Chromium issue 513006636 containing the root cause is access-restricted.

Severity — differs by source. The vendor (Chromium) itself rates it Medium, CISA-ADP's CVSS v3.1 is 9.6 CRITICAL (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H), and there is no NVD own assessment. Both are stated side by side without ruling which is correct — the interpretation is in docs/cve-2026-13934/overview.md.

This repository has no deployed services (APIs, backends, databases, etc.). All artifacts are documents.

Key conclusions

1. Root cause — the precondition required by the specification was not checked

The Vulkan specification requires that for samplers with YCbCr conversion, the address mode of all axes is CLAMP_TO_EDGE and anisotropic filtering is disabled (VUID-VkSamplerCreateInfo-addressModeU-01646). Before the patch, Dawn did not check this constraint, so specification-violating parameters could pass validation and reach VkSampler creation.

The decisive point is the threat model. The public description assumes an attacker who already controls the renderer process ("a remote attacker who had compromised the renderer process"). From that position, inter-process commands can be manipulated directly rather than going through the normal web API path, so renderer-side validation is outside the trust boundary. And Dawn's Vulkan backend runs in the GPU process, which has higher privileges than the renderer — which is why this flaw becomes a sandbox escape surface.

Basis: cases/20260804-cve-2026-13934-4d10a8/root_cause.md §2 · Details: docs/cve-2026-13934/root-cause-and-fix.md

2. Fix — did not stop at a single layer of validation

The fixing commit is Dawn 43055cbeadddca41a9c973a809f859d641077b2f ("Add YCbCr sampler validation", 2026-05-27, Bug: 513006636) and changes three files.

This structure is the core of this CVE. Because the renderer is assumed to be already compromised, validation alone is insufficient; the second layer, which enforces values on the higher-privilege side, is the substantive line of defense. Summarizing this as "input validation was missing, so validation was added" misses the point of the defense design.

The change scale is 53 additions, 0 deletions — a patch that fills in the missing checks without modifying existing logic.

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

3. Demonstration — verified to the static level

We compared the source of the two Dawn snapshots actually pinned by Chrome.

What this revealed: the vulnerable side also already had a YCbCr branch and 2 checks. The flaw was not a missing path but a missing conditional-constraint check inside the branch.

Since we did not build or run, the two items below are expected values based on the code, not measurements.

Basis: cases/20260804-cve-2026-13934-4d10a8/report.md §1–§4 · Details: docs/cve-2026-13934/evidence.md

4. Lessons

From a security design perspective

• Values crossing a trust boundary must be handled again on the side they enter. Client/renderer-side validation is for convenience and diagnostics; inside the privilege boundary, values must be validated or enforced.
• "Preconditions required by the specification" are not upheld unless enforced in code. A conditional constraint must be handled in the branch where that condition holds; in this case the branch existed and only the check was missing.
• Reject and clamp have different roles. This patch rejects on normal paths and applies clamping to values coming from outside the trust boundary.
• Do not judge based on a single severity number. The same vulnerability has both a vendor rating of Medium and a CVSS 9.6 CRITICAL. The actual risk only becomes visible when the premise (prior renderer compromise) is read together.
• Do not invert the direction of detection signals. Validation error messages occur only after the patch. Reasoning that "there is no such error in the logs, so it must be safe" is backwards.

From an investigation methodology perspective

• The fix can be traced even when the CVE reference link has no patch. The fixing commit was found via vendor advisory bug number → release comparison tags → component revision in DEPS → searching the component commit log for the bug number. Procedure: research/20260804-cve-2026-13934-diff-92f928/sources.md §6.
• Regression tests are the best observation specification. The test shipped with the patch defines "which input yields which result," so the before/after difference can be confirmed without a risky reproduction.
• Do not mix confirmed and inferred items. The artifacts in this repository do not leave unconfirmed items as blanks but record them as "unconfirmed + reason."

Details: docs/cve-2026-13934/lessons.md

Artifacts

Learning documents (docs/)

Investigation — public information and impact scope (research/20260804-cve-2026-13934-6bacf7/)

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

Analysis — reproduction/demonstration (for learning) (cases/20260804-cve-2026-13934-4d10a8/)

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

External primary sources (summary)

• CVE Record: https://www.cve.org/CVERecord?id=CVE-2026-13934
• NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-13934
• Vendor advisory: Chrome Releases "Stable Channel Update for Desktop" (2026-06-30)
• Fixing commit: https://dawn.googlesource.com/dawn/+/43055cbeadddca41a9c973a809f859d641077b2f

The full list with publication dates and identifiers is in the sources.md files of the two investigation tracks.

Periodic collection: research/topics/<topic>/

Rules (summary)

• Commit text only. Binaries, dumps, and screenshots are prohibited. Each file ≤ 1 MiB.
• Allowed paths: research/ · cases/ · work/ · reports/ · docs/ · .laurelin/ · .github/
• Humans do not commit directly; instructions are given in the Laurelin work project → Aulë commits.
• Detailed conventions: docs/conventions.md