Ignoring a failure result and using the partial output
A fallible operation, such as serialization, page decommit, a partial clear, or an archive-entry unpack, returns a failure or partial-completion signal that the caller does not check, then proceeds to consume the incomplete or invalid output as if the operation had fully succeeded. This causes stale or uninitialized memory to be reused, an invalid value to be trusted, or a corrupt artifact to be reported as valid. The unifying flaw is a missing failure branch or an all-or-nothing flag that cannot represent partial progress.
Mechanism
Fix shape
CVEs in this pattern
3 components · Skia, V8, Installer| CVE | What | Component | Vendor | Severity | Month | |
|---|---|---|---|---|---|---|
| CVE-2026-87548 | InputValidation in Installer | Installer | chrome | Medium | 2026-09 | 🔧 |
| CVE-2026-91747 | UAF in Skia | Skia | chrome | High | 2026-09 | 🔧 |
| CVE-2026-78914 | UninitializedMemory in Skia | Skia | chrome | Low | 2026-08 | 🔧 |
| CVE-2026-15766 | UninitializedMemory in Skia | Skia | chrome | High | 2026-07 | 🔧 |
| CVE-2026-11649 | UAF in V8 | V8 | chrome | High | 2026-06 | 🔧 |
| CVE-2026-14405 | UninitializedMemory in V8 | V8 | chrome | Low | 2026-06 | 🔧 |
Hunt for siblings
Static analysis should flag discarded return values of fallible functions (serialization Responses, DecommitPages, unpack) and boolean flags that gate initialization or validation; auditors should look for early success returns that skip populating results on the failure path.
Mitigations that would catch this class
- Treat fallible APIs as must-check; propagate or hard-fail (CHECK) on error rather than continuing with a partial result.
- Represent completion as the concrete region/range covered, not a single all-or-nothing boolean.
- Ensure security-relevant validators explicitly touch their result/output on every path, including failure fall-through.