Closed Bug 1986431 (CVE-2025-13021) Opened 1 year ago Closed 1 year ago

SEGV on unknown address with very high WGSL group binding index

Categories

(Core :: Graphics: WebGPU, defect, P1)

Product:
Core
Component:
Graphics: WebGPU
Version:
Firefox 144
Platform:
Unspecified
Linux
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
146 Branch
Tracking Flags:
Tracking Status
firefox-esr128 --- disabled
firefox-esr140 --- disabled
firefox142 --- disabled
firefox143 --- disabled
firefox144 --- disabled
firefox145 + fixed
firefox146 + fixed

People

(Reporter: attekett, Assigned: jimb)

References

Details

(4 keywords, Whiteboard: [fixed in 1995050] [adv-main145+])

Attachments

(2 files, 1 obsolete file)

SEGV-e8cc-createdescriptorsetlayout-createbindgrouplayout.html
2.31 KB, text/html
Details
Rust code to reproduce the crash using wgpu directly
2.68 KB, text/rust
Details

Tested on:
OS: Ubuntu 24.04
Firefox: fuzzfetch fetched --asan --fuzzing
> Task ID: GBCaDi1mT-6BdjWafeV9Jw
> Rank: 1756806487
> Changeset: cde4cacceebc4e36c6bf2d53166ee0b8922596c6
> Build ID: 20250902094807

Test case defines: '@group(0) @binding(390000000) var<uniform> uni: Uniforms;' in the shader code. Binding index is far outside of the maxBindingsPerBindGroup. Decreasing the index will prevent the crash.

FYI, There is a spike in memory usage before the crash, which made me think about bug 1927289, which is about OOM triggering bad behavior.

ASAN-trace:

Crash Annotation GraphicsCriticalError: |[C0][GFX1-]: WebGPU: disabling SharedTexture swapchain: 
missing GBM_FORMAT_ARGB8888 dmabuf format (t=10.9189) [GFX1-]: WebGPU: disabling SharedTexture swapchain: 
missing GBM_FORMAT_ARGB8888 dmabuf format
AddressSanitizer:DEADLYSIGNAL
=================================================================
==2640822==ERROR: AddressSanitizer: SEGV on unknown address (pc 0x7fff3b107ded bp 0x7fff9da62b10 sp 0x7fff9da62a30 T43)
==2640822==The signal is caused by a READ memory access.
==2640822==Hint: this fault was caused by a dereference of a high value address (see register values below).  Disassemble the provided pc to learn which register was used.
    #0 0x7fff3b107ded  (/usr/lib/x86_64-linux-gnu/libvulkan_radeon.so+0x107ded) (BuildId: 4c73d51a265843a977afae4f4bc51b884f49b0ae)
    #1 0x7fffe4987e5a in ash::device::Device::create_descriptor_set_layout::h331a067e512a93f3 /builds/worker/checkouts/gecko/third_party/rust/ash/src/device.rs:1567:9
    #2 0x7fffe4987e5a in wgpu_hal::vulkan::device::_$LT$impl$u20$wgpu_hal..Device$u20$for$u20$wgpu_hal..vulkan..Device$GT$::create_bind_group_layout::h3e59838ad15b4b65 /builds/worker/checkouts/gecko/third_party/rust/wgpu-hal/src/vulkan/device.rs:1582:13
    #3 0x7fffe405d179 in _$LT$D$u20$as$u20$wgpu_hal..dynamic..device..DynDevice$GT$::create_bind_group_layout::hd54f96023492a589 /builds/worker/checkouts/gecko/third_party/rust/wgpu-hal/src/dynamic/device.rs:278:18
    #4 0x7fffe4775bb7 in wgpu_core::device::resource::Device::create_bind_group_layout::h20fa3847b8a7929c /builds/worker/checkouts/gecko/third_party/rust/wgpu-core/src/device/resource.rs:2462:28
    #5 0x7fffe4218afa in wgpu_core::device::resource::Device::derive_pipeline_layout::_$u7b$$u7b$closure$u7d$$u7d$::h2fbed99cd79def53 /builds/worker/checkouts/gecko/third_party/rust/wgpu-core/src/device/resource.rs:3440:31
.
.
.
    #42 0x5555556b7766 in asan_thread_start(void*) /builds/worker/fetches/llvm-project/compiler-rt/lib/asan/asan_interceptors.cpp:239:28
    #43 0x7ffff789caa3 in start_thread nptl/pthread_create.c:447:8
    #44 0x7ffff7929c3b in clone3 misc/../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

==2640822==Register values:
rax = 0x0000000000000006  rbx = 0x000050300265ac50  rcx = 0x0000000000000000  rdx = 0x0000000000000010  
rdi = 0x00000000173eed80  rsi = 0x00000000a2b87e80  rbp = 0x00007fff9da62b10  rsp = 0x00007fff9da62a30  
 r8 = 0x00007fff9bfadfb0   r9 = 0x000050300265ac50  r10 = 0x0000000000000000  r11 = 0x00000000173eed80  
r12 = 0x0000000000000000  r13 = 0x00007ffddcbe2800  r14 = 0x0000000000000001  r15 = 0x0000000000000001  
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (/usr/lib/x86_64-linux-gnu/libvulkan_radeon.so+0x107ded) (BuildId: 4c73d51a265843a977afae4f4bc51b884f49b0ae) 
Thread T43 created by T0 here:
    #0 0x5555556a0d41 in pthread_create /builds/worker/fetches/llvm-project/compiler-rt/lib/asan/asan_interceptors.cpp:250:3
    #1 0x7ffff7a80419 in _PR_CreateThread /builds/worker/checkouts/gecko/nsprpub/pr/src/pthreads/ptthread.c:429:10
    #2 0x7ffff7a6e65e in PR_CreateThread /builds/worker/checkouts/gecko/nsprpub/pr/src/pthreads/ptthread.c:496:10
    #3 0x7fffd3f74291 in nsThread::Init(nsTSubstring<char> const&) /builds/worker/checkouts/gecko/xpcom/threads/nsThread.cpp:615:20
.
.
.
    #46 0x7ffff782a28a in __libc_start_main csu/../csu/libc-start.c:360:3
    #47 0x55555561dc08 in _start (/home/attekett/Downloads/firefox/firefox+0xc9c08) (BuildId: f4ce53d20295d096e0db42c97c1cb980d797f317)

==2640822==ABORTING

For WebGL firefox shows:

WebGL 1 Driver Renderer	NVIDIA Corporation -- NVIDIA GeForce RTX 3090/PCIe/SSE2
WebGL 1 Driver Version	4.6.0 NVIDIA 550.163.01

But for WebGPU

WebGPU Default Adapter	{
  "navigator.gpu.requestAdapter({})": {
    "info": {
      "architecture": "",
      "description": "",
      "device": "",
      "isFallbackAdapter": false,
      "subgroupMaxSize": 128,
      "subgroupMinSize": 4,
      "vendor": "",
      "wgpuBackend": "Vulkan",
      "wgpuDevice": 5056,
      "wgpuDeviceType": "IntegratedGpu",
      "wgpuDriver": "radv",
      "wgpuDriverInfo": "Mesa 25.0.7-0ubuntu0.24.04.1",
      "wgpuName": "AMD Radeon Graphics (RADV RAPHAEL_MENDOCINO)",
      "wgpuVendor": 4098
    },
    "features": [
      "bgra8unorm-storage",
      "core-features-and-limits",
      "depth-clip-control",
      "depth32float-stencil8",
      "float32-filterable",
      "indirect-first-instance",
      "rg11b10ufloat-renderable",
      "shader-f16",
      "texture-compression-bc",
      "texture-compression-bc-sliced-3d",
      "timestamp-query"
    ],
    "limits": {
      "maxBindGroups": 8,
      "maxBindGroupsPlusVertexBuffers": 24,
      "maxBindingsPerBindGroup": 1000,
      "maxBufferSize": 1073741824,
      "maxColorAttachmentBytesPerSample": 32,
      "maxColorAttachments": 8,
      "maxComputeInvocationsPerWorkgroup": 1024,
      "maxComputeWorkgroupSizeX": 1024,
      "maxComputeWorkgroupSizeY": 1024,
      "maxComputeWorkgroupSizeZ": 1024,
      "maxComputeWorkgroupStorageSize": 65536,
      "maxComputeWorkgroupsPerDimension": 65535,
      "maxDynamicStorageBuffersPerPipelineLayout": 8,
      "maxDynamicUniformBuffersPerPipelineLayout": 16,
      "maxInterStageShaderVariables": 16,
      "maxSampledTexturesPerShaderStage": 64,
      "maxSamplersPerShaderStage": 64,
      "maxStorageBufferBindingSize": 1073741824,
      "maxStorageBuffersPerShaderStage": 64,
      "maxStorageTexturesPerShaderStage": 64,
      "maxTextureArrayLayers": 2048,
      "maxTextureDimension1D": 16384,
      "maxTextureDimension2D": 16384,
      "maxTextureDimension3D": 2048,
      "maxUniformBufferBindingSize": 1073741824,
      "maxUniformBuffersPerShaderStage": 64,
      "maxVertexAttributes": 32,
      "maxVertexBufferArrayStride": 2048,
      "maxVertexBuffers": 16,
      "minStorageBufferOffsetAlignment": 32,
      "minUniformBufferOffsetAlignment": 32
    }
  }
}
Group: core-security → gfx-core-security
Severity: -- → S3
status-firefox142: --- → disabled
status-firefox143: --- → disabled
status-firefox144: --- → disabled
status-firefox-esr128: --- → disabled
status-firefox-esr140: --- → disabled
OS: Unspecified → Linux
Priority: -- → P1

Binding index is far outside of the maxBindingsPerBindGroup. Decreasing the index will prevent the crash.

Is there a discernible relation between the address we're trying to access and the binding index? Currently can't tell if this could be exploitable or not.

We can mark the 144 status "disabled" when it's on beta, but on nightly it's currently "affected". We really need a "nightly-only" status.

status-firefox144: disabled → affected
Keywords: csectype-bounds, sec-high
Assignee: nobody → jimb

Crash report from nightly-firefox on Ubuntu: https://crash-stats.mozilla.org/report/index/e4ce37a0-5e95-429f-b8a8-d0fa00250908

From what I can gather, it looks like the binding index is used in an offset calculation for a write operation, so there is a direct relation.

7FFEAED07DC2: 48 8D 34 FD 00 00 00 00         leaq   (,%rdi,8), %rsi
7FFEAED07DCA: 48 29 FE                        subq   %rdi, %rsi
7FFEAED07DCD: 41 C7 84 B5 C0 00 00 00 10 >    movl   $0x10, 0xc0(%r13,%rsi,4)

We end up crashing in an address: <stack_address> + 0xc0 + (<binding_index> * 7 * 4)

For example when running with a test case that has binding(1000000000):

%r13 = 0x00007ffe1ae3f800 # stack_address
%rdi = 0x000000003b9aca00 # 1000000000
%rsi = 0x00000001a13b8600 # 7000000000

Final address: 0x80049FD210C0

I'm able to reproduce this crash locally.

It seems like implicit bind group layout creation skirts the checks applied by wgpu_core::device::bgl::EntryMap::from_entries. Either those checks should be moved into wgpu_core::device::resource::Device::create_bind_group_layout, or the latter should be changed to use the former.

Here's Rust code to reproduce this without a browser. Accompanying Cargo.toml:

[package]
name = "testcase"
version = "0.1.0"
edition = "2024"

[dependencies]
anyhow = "1"
pollster = "0.4"
wgpu = "25"

The process from here will be to fix it upstream in wgpu, and then bring that fix into Mozilla Central with the next revendoring.

Once you have an upstream issue or PR please add them to the "see also" field

Flags: needinfo?(jimb)
Status: NEW → ASSIGNED
Flags: sec-bounty?
Flags: needinfo?(jimb)
See Also: → https://github.com/gfx-rs/wgpu/pull/8325

wgpu#8325 should fix this bug.

No longer blocks: 1994319
Depends on: 1994319
Blocks: 1994319
No longer depends on: 1994319

I've marked bug 1994319 as a dependent of this bug, since it (by necessity) aggregates several bugfixes from a wgpu revendor.

The bug is marked as tracked for firefox145 (beta). However, the bug still has low severity.

:bhood, could you please increase the severity for this tracked bug? If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit BugBot documentation.

Flags: needinfo?(bhood)
Severity: S3 → S2

This should be fixed in mozilla central now. Atte, could you confirm?

Flags: needinfo?(attekett)

I'm travelling and don't have any Linux machine with me. As the bug doesn't reproduce on Xvfb and VNC, I have limited testing capabilities with remote.

I tested with one remote machine that has AMD GPU and autologin desktop. It is different machine than the one I used to find the issue.

The test case from the original report causes OOM when using ASAN build downloaded with the BuildID from the report. There is no OOM, or other crashe, when using new build.

Tested with:

[Build]
BuildID=20251021093256
Milestone=146.0a1
SourceStamp=371a2ab12ddfc637c94e4d7883518671241283ff

I hope this helps. I'll check again when I get back home and on the machine I found and reported the issue with.

Flags: needinfo?(attekett)

Back at home.

Can verify that the reported issue doesn't reproduce anymore.

There is no OOM on the computer I used to minimize the reproducing file, only a debug console message about Binding index being greater than maximum.

Thank you very much for re-testing!

Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Group: gfx-core-security → core-security-release
status-firefox146: --- → fixed
tracking-firefox146: --- → +
Whiteboard: [fixed in 1995050]
Flags: needinfo?(bhood)
Target Milestone: --- → 146 Branch
QA Whiteboard: [sec] [uplift] [qa-triage-done-c146/b145]
Whiteboard: [fixed in 1995050] → [fixed in 1995050] [adv-main145+]
Attached file advisory.txt (obsolete) —
Attachment #9525031 - Attachment is obsolete: true
Alias: CVE-2025-13021
Flags: sec-bounty? → sec-bounty+
Keywords: csectype-sandbox-escape

We are considering this a "sandbox escape" bounty because it's a partially controllable write in a more privileged process.

See Also: → 1997866
See Also: → CVE-2026-6773
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: