Chrome · V8 › Base
CVE-2026-14405
Uninitialized Memory in V8 (Base)
Low
watch
CVSS 9.6
chrome
Uninitialized Memory
🔧 Commit mapped
🧬 Ignoring a failure result and using the partial output
Overview
Low
Severity
9.6
CVSS
No
Exploited ITW
Fixed
Fix Status
Background
- `base::BoundedPageAllocator`
- a page allocator that hands out virtual-memory pages from a fixed, bounded region and delegates the actual OS operations to a wrapped
page_allocator_. - `kAllocatedPagesMustBeZeroInitialized`
- an allocator initialization mode that promises every page returned to a caller is zero-filled, so callers may skip re-zeroing memory.
- `DecommitPages`
- the OS-level operation that unmaps/decommits a page range so that any physically wired pages are dropped and the range reads back as zero when next touched.
- `CHECK`
- a V8 runtime assertion that unconditionally aborts the process if its condition is false, in both debug and release builds.
Root Cause Analysis
In the branch guarded by the zero-initialization requirement, the code called success = page_allocator_->DecommitPages(raw_address, size) to reclaim a page range but then ignored the success result and fell through to return the range to the free pool. When the OS could not complete the decommit (the commit message cites running out of VMAs to create the range), the pages were left in whatever state they held — still carrying previously written data rather than being zeroed — yet the allocator would later re-hand them out under the kAllocatedPagesMustBeZeroInitialized contract that promises zeroed memory. The invariant violated is that under this mode every returned page must be zero-initialized; a failed DecommitPages silently broke it.
The fix adds CHECK(success) immediately after the decommit call, so a failure to zero the range terminates the process instead of recycling stale, non-zeroed memory into a caller that trusts it is zeroed.
Key insight
The single mistake was consuming a fallible
DecommitPages result without checking it while promising zero-initialized pages; the fix converts that silent failure into a hard CHECK(success) crash so stale memory can never be recycled as if it were zeroed.Attack Path
- Induce decommit failure
Drive the process into a state where the OS cannot create the VMAs needed to decommit a range (e.g. VMA/mapping exhaustion), so
DecommitPagesreturnsfalse. (inferred) - Stale range recycled
With the pre-patch code, the failed decommit is ignored and the still-populated page range is returned to the free pool despite the
kAllocatedPagesMustBeZeroInitializedcontract. - Reallocation over dirty memory A subsequent allocation receives that range and, trusting the zero-initialization guarantee, does not re-zero it, so it observes leftover data from the prior owner.
- Uninitialized use Downstream code reads the assumed-zero memory and instead consumes attacker-influenced or sensitive residual bytes, matching the advisory’s “Uninitialized Use in V8” impact. (inferred)
Impact Assessment
An attacker who can trigger the decommit-failure condition can cause zero-assuming allocations to receive stale, non-zeroed pages, yielding uninitialized-memory use within the V8/renderer process; the advisory classifies this as
UninitializedMemory / “Uninitialized Use in V8” and does not report in-the-wild exploitation. The precondition is reaching the failure path (OS resource exhaustion preventing decommit), and any escalation from information disclosure to a stronger primitive is (inferred).Changed Functions
| Function | Change | Notes |
|---|---|---|
switchsrc/base/bounded-page-allocator.cc |
modified |
Files Changed
src/base/bounded-page-allocator.cc
Audit Directions
- Ignored fallible cleanup resultsGrep for calls to
DecommitPages,DiscardSystemPages,SetPermissions, and similar OS-fallible operations whose return value is assigned but never checked on a path that later reuses the memory. - Zero-init contract pathsAudit every code path gated on
kAllocatedPagesMustBeZeroInitialized(or callers that skip re-zeroing) to confirm each guarantees a successful zeroing/decommit before the range re-enters the free pool. - Failure-mode fall-throughLook for allocator/free routines that continue to a common return after a failed sub-operation instead of crashing or propagating the error, especially where a security invariant (zeroing, inaccessibility) is being promised.
Patch
From 5a2bdebda1f4a376af6d9a629d5bbe63026a9bb2 Mon Sep 17 00:00:00 2001 From: Michael Lippautz <[email protected]> Date: Fri, 15 May 2026 10:56:59 +0000 Subject: [PATCH] [base] Fix potential stale memory With kAllocatedPagesMustBeZeroInitialized we must crash in case the OS runs out of VMAs to create. Fixed: 513376037 Change-Id: I2534e33ad98c3e06a1ff63507f86600f8c3e2824 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7849375 Reviewed-by: Igor Sheludko <[email protected]> Auto-Submit: Michael Lippautz <[email protected]> Commit-Queue: Igor Sheludko <[email protected]> Cr-Commit-Position: refs/heads/main@{#107342} --- diff --git a/src/base/bounded-page-allocator.cc b/src/base/bounded-page-allocator.cc index de53e0d..5e273cf 100644 --- a/src/base/bounded-page-allocator.cc +++ b/src/base/bounded-page-allocator.cc @@ -213,6 +213,9 @@ // When we are required to return zero-initialized pages, we decommit the // pages here, which will cause any wired pages to be removed by the OS. success = page_allocator_->DecommitPages(raw_address, size); + // Since we require zero-initialized pages, we must fail here if we cannot + // decomitt the range. + CHECK(success); } else { switch (page_freeing_mode_) { case PageFreeingMode::kMakeInaccessible:
Loading diff…
Original Bug Report
The reporter's bug is still restricted on the tracker. Chrome de-restricts security bugs ~30–90 days after the fix ships; a later run will backfill it here.
References
On This Page