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.

Overview: A potential Use-After-Free and call into an unloaded module exists in the WebNN ONNX Runtime (ORT) backend. The issue arises from a C++ object destruction order flaw where the ORT environment is destroyed before its dependent tensor objects. This prematurely unloads execution provider DLLs, leading to execution in unmapped memory and potential RCE in the GPU process.

Affected files:

• services/webnn/ort/context_impl_ort.h
• services/webnn/ort/device_allocator.h
• services/webnn/ort/tensor_impl_ort.h
• services/webnn/webnn_context_impl.h
• services/webnn/ort/environment.cc

Estimated timestamp from git blame: 2025-10-03

Summary

A potential Use-After-Free (UAF) and call-into-unloaded-module vulnerability exists in the WebNN ONNX Runtime (ORT) backend during context destruction. A C++ object destruction order flaw causes the Environment object to be released before the tensors and allocators that depend on it. Consequently, ORT execution provider (EP) DLLs are unloaded while objects still hold function pointers or need to call cleanup functions within those DLLs, leading to a crash or potential Remote Code Execution (RCE) in the GPU process.

Technical Details

In services/webnn/ort/context_impl_ort.h, the ContextImplOrt class inherits from WebNNContextImpl.

ContextImplOrt declares several members, importantly:

scoped_refptr<Environment> env_;
// ...
scoped_refptr<DeviceAllocator> device_allocator_;

Its base class, WebNNContextImpl (services/webnn/webnn_context_impl.h), holds the tensors:

base::flat_set<scoped_refptr<WebNNTensorImpl>, ...> tensor_impls_;

When a ContextImplOrt object is destroyed, C++ standard destruction rules dictate that derived class members are destroyed before base class members.

1. Derived members destroyed: ContextImplOrt::env_ is destroyed. If this is the last reference to the global Environment singleton, Environment::Release() is called. This invokes the ORT C API ReleaseEnv, which unloads the execution provider DLLs (e.g., OpenVINO, DirectML) from the GPU process’s address space.
2. Base members destroyed: WebNNContextImpl::tensor_impls_ is subsequently destroyed, which triggers the destruction of any contained TensorImplOrt instances.
3. Call into unmapped memory: TensorImplOrt holds a ScopedOrtValue (tensor_) and a scoped_refptr<DeviceAllocator>. DeviceAllocator in turn holds a ScopedOrtSession. When these objects are destructed, their cleanup traits automatically call ORT C APIs like ReleaseValue and ReleaseSession. These functions rely on the underlying Execution Provider to free device memory. Because the EP DLL was already unloaded in step 1, execution jumps into unmapped memory space.

Impact

This vulnerability triggers execution of code in unmapped memory regions within the unsandboxed GPU process. If an attacker can groom the GPU process address space (e.g., via WebGPU or WebGL allocations) to map attacker-controlled data into the space previously occupied by the unloaded DLL, this could potentially result in Remote Code Execution (RCE).

Potential Reproduction Steps

Note: These are suggested/potential steps based on code analysis, as our tooling agent cannot execute code to verify the PoC directly.

1. Enable the WebNN feature flag (chrome://flags#web-machine-learning-neural-network) on a supported platform (e.g., Windows with NPU/GPU).
2. Create a WebNN context using a device type that utilizes an execution provider DLL (e.g., navigator.ml.createContext({deviceType: 'npu'})).
3. Create at least one tensor using context.createTensor(...) to populate tensor_impls_.
4. Trigger destruction of the context (e.g., by dropping references and forcing JavaScript Garbage Collection, or closing the tab).
5. The GPU process will crash attempting to execute teardown functions from the unloaded DLL.

Suggested Fix

The destruction order must be corrected to ensure that tensor_impls_ (and any other ORT objects, like graphs) are destroyed before the Environment.

This can be resolved by explicitly clearing tensor_impls_ and graph_impls_ in the ~ContextImplOrt() destructor before the derived class members are automatically destroyed:

ContextImplOrt::~ContextImplOrt() {
  // Ensure tensors and graphs are destroyed before the ORT environment to 
  // prevent calling into unloaded execution provider DLLs.
  tensor_impls_.clear();
  graph_impls_.clear();
}

Evaluated with Chrome root at commit: 096fc8fdbfacf2546485756d03f160a3d04fcc9b

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.