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. Please see https://chromium.googlesource.com/chromium/src/+/main/docs/security/ai-generated-security-bugs-faq.md for more information.

Overview: The XRFrame::fillPoses method in Blink’s WebXR implementation is vulnerable to a potential write-after-free. The function captures a base::span from a JavaScript-owned Float32Array and subsequently triggers synchronous JavaScript execution via the XRSpace::getPose method. An attacker can detach the underlying ArrayBuffer during this execution, causing subsequent writes to the stale span to corrupt memory.

Affected files:

• third_party/blink/renderer/modules/xr/xr_frame.cc
• third_party/blink/renderer/modules/xr/xr_bounded_reference_space.cc
• third_party/blink/renderer/modules/xr/xr_space.cc
• third_party/blink/renderer/modules/xr/xr_reference_space.cc

Estimated timestamp from git blame: 2024-10-21

Root Cause Analysis

In third_party/blink/renderer/modules/xr/xr_frame.cc, the fillPoses method retrieves a base::span from the provided Float32Array before entering a loop to populate it with pose data:

// xr_frame.cc:570
auto transforms_data = transforms->AsSpan();
for (const auto& space : spaces) {
  auto current_transform = transforms_data.take_first<kFloatsPerTransform>();
  if (const XRPose* pose = space->getPose(base_space)) {
    current_transform.copy_from(pose->transform()->matrix()->AsSpan());
  } else {
    std::ranges::fill(current_transform, NAN);
  }
}

The transforms_data span is a snapshot of the array’s backing store. Within the loop, space->getPose(base_space) is invoked. If the space is an XRBoundedReferenceSpace, this call leads to XRBoundedReferenceSpace::EnsureUpdated() in third_party/blink/renderer/modules/xr/xr_bounded_reference_space.cc (line 104), which dispatches a synchronous reset event:

mutable_this->DispatchEvent(
    *XRReferenceSpaceEvent::Create(event_type_names::kReset, mutable_this));

DispatchEvent is a synchronous call that executes JavaScript event listeners. An attacker can use this callback to detach the transforms buffer (e.g., via postMessage). When the callback returns, the transforms_data span in fillPoses still holds a raw pointer to the now-detached or freed memory. Subsequent calls to copy_from or std::ranges::fill result in a write-after-free.

Potential Impact

This vulnerability allows an attacker to perform a controlled write-after-free within the sandboxed renderer process. The attacker can control the contents of the write (via the poses of the spaces) and the location of the write within the ArrayBuffer partition. Since ArrayBuffer backing stores are not protected by MiraclePtr (BackupRefPtr) and often reside in the V8 sandbox cage, this primitive could be leveraged to corrupt V8 objects and achieve remote code execution (RCE) within the renderer.

Suggested Potential Reproduction Steps

1. Establish an immersive VR session with ‘bounded-floor’ support.
2. Create a sequence of XRBoundedReferenceSpace objects.
3. Attach a reset event listener to one of the spaces.
4. In the listener, transfer the Float32Array buffer intended for fillPoses to a Worker to detach it.
5. Call xrFrame.fillPoses() with the space sequence and the target array.
6. Observe a crash or heap corruption when fillPoses attempts to write to the second or subsequent spaces in the sequence.

Recommended Fix

The base::span should not be held across points of synchronous JavaScript execution. The code should be modified to either:

1. Re-acquire the span from the DOMFloat32Array inside the loop after the call to getPose.
2. Validate that the buffer has not been detached after returning from getPose before performing the write.
3. Pre-calculate all poses before capturing the span for the output buffer.

Evaluated with Chrome root at commit: 1a8d40fc44df2088d5945c0bf53584038aa1614a

Results so far have been promising, but there can be wrong deductions. Feel free to adjust as follows:

• If you are familiar with the severity guidelines, you may adjust the severity.
• If this is a false positive, and there’s no work to be done, please close as WAI.
• If there is work to do here but not a vulnerability, please change the issue type to Task/Bug/FR.

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.