Project Fortify, an experimental security project, has identified the following potential security issue. If you’re a feature owner CC-ed on this bug, please do your best to review these reports without the Chrome Security team. Please see https://chromium.googlesource.com/chromium/src/+/main/docs/security/ai-generated-security-bugs-faq.md for more information.

Overview: A potential Use-After-Free and Double-Free vulnerability exists in Perfetto’s protovm component due to stale pointer retention in RwProtoCursor::Delete. A compromised renderer can trigger this by submitting crafted trace data containing nested VM instructions. On platforms like Android and CastOS, this could lead to memory corruption and sandbox escape within the browser process.

Affected files:

• third_party/perfetto/src/protovm/rw_proto_cursor.cc
• third_party/perfetto/src/protovm/rw_proto_cursor.h
• third_party/perfetto/src/protovm/parser.cc
• third_party/perfetto/src/protovm/slab_allocator.h
• third_party/perfetto/src/trace_processor/importers/proto/proto_trace_reader.cc
• third_party/perfetto/src/trace_processor/importers/proto/protovm_incremental_tracing.cc

Estimated timestamp from git blame: 2025-04-28

Description

A potential Use-After-Free (UAF) and Double-Free vulnerability exists in the Perfetto protovm component. The RwProtoCursor::Delete() method improperly manages its internal state during deletion, leaving stale pointers that can be exploited via nested Virtual Machine (VM) instructions.

Initial logic and packet stream validation parameters are correctly established, allowing a compromised renderer to inject a VM program into the tracing service. When the Parser executes a del instruction containing nested del instructions, the parser invokes RwProtoCursor::Delete() consecutively on the same cursor.

The final transformation occurs because Delete() nullifies the node_ pointer but leaves holding_map_and_node_ fully populated. In release builds, PERFETTO_DCHECK(node_) is optimized out, allowing the nested execution to leap directly to the uncleared holding_map_and_node_ pointers. The secondary Delete() invocation triggers a Use-After-Free write via IntrusiveTree::Remove() pointer re-linking on the stale map_node, followed immediately by a SlabAllocator double-free that creates a cyclic free-list loop. This establishes guaranteed memory aliasing and type-confusion primitives.

Because Perfetto’s SlabAllocator relies directly on base::PagedMemory::Allocate (mmap) rather than PartitionAlloc, standard Chromium mitigations such as MiraclePtr (BackupRefPtr) do not apply.

On Android and CastOS, the tracing service runs directly within the Browser process (features::kTracingServiceInProcess is enabled by default). Consequently, a compromised renderer can achieve browser-process memory corruption and a sandbox escape.

Potential Attacker Steps

(Note: These are suggested/potential steps derived from code analysis; our tooling agent does not have the ability to run active code.)

1. Initial logic and parameters are validated: A compromised renderer emits a TracePacket containing a trace_provenance field (ID 124) to map its producer ID to a sequence ID.
2. The renderer emits a TracePacket containing a protovms field (ID 125) with a VmProgram.
3. Standard processing applied: The program contains a select instruction followed by a del instruction, where the outer del contains a nested del instruction targeting the same cursor.
4. Standard processing applied: The user or system initiates and concludes a tracing session that includes the malicious data source.
5. The tracing service parses the trace, hitting the malicious nested VM instruction. The secondary Delete() invocation executes the final transformation, triggering the UAF and Double-Free memory corruption.

Suggested Fix

Explicitly clear the holding_map_and_node_ tuple inside third_party/perfetto/src/protovm/rw_proto_cursor.cc during the RwProtoCursor::Delete() operation to prevent subsequent operations from accessing stale pointers.

  holding_map->Remove(*map_node);
  allocator_->Delete(&GetOuterNode(*map_node));

  node_ = nullptr;
  holding_map_and_node_ = {}; // FIX: Clear stale map and node pointers

Evaluated with Chrome root at commit: eca8648a4e1cdfdda68c495a6003059fed641955

Results so far have been promising, but there can be wrong deductions. If this proves to be a false positive, please close as WAI; data from false positives will be used to improve accuracy over time. And please feel free to reach out to me directly if you have concerns or feedback on the project.