Closed Bug 1770219 Opened 2 years ago Closed 2 years ago

AddressSanitizer: negative-size-param: (size=-2147483648) [@ __interceptor_memcpy]


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




104 Branch
Tracking Status
firefox-esr91 --- disabled
firefox-esr102 104+ fixed
firefox102 --- wontfix
firefox103 --- wontfix
firefox104 + fixed


(Reporter: jkratzer, Assigned: nical)


(Blocks 2 open bugs)


(Keywords: csectype-bounds, sec-high, Whiteboard: [bugmon:confirm][adv-main104+r][adv-esr102.2+r])


(4 files)

Found while fuzzing mozilla-central rev cc776278c4ea (built with: --enable-address-sanitizer --enable-fuzzing).

The stack included here isn't very helpful but I do have a testcase that I'm currently reducing. I will update this bug once complete.

AddressSanitizer: negative-size-param: (size=-2147483648) [@ __interceptor_memcpy]

    ==12055==ERROR: AddressSanitizer: negative-size-param: (size=-2147483648)
        #0 0x5570c1edd1f5 in __interceptor_memcpy /builds/worker/fetches/llvm-project/compiler-rt/lib/asan/../sanitizer_common/
        #1 0x7f51dde17b09  (/usr/lib/x86_64-linux-gnu/ (BuildId: 1106af37206701c77fa5fccb2899f73413b732e0)
        #2 0x7f51ddfbc0ac  (/usr/lib/x86_64-linux-gnu/ (BuildId: 1106af37206701c77fa5fccb2899f73413b732e0)
        #3 0x7f51ddda7226  (/usr/lib/x86_64-linux-gnu/ (BuildId: 1106af37206701c77fa5fccb2899f73413b732e0)
        #4 0x7f51ddda8da1  (/usr/lib/x86_64-linux-gnu/ (BuildId: 1106af37206701c77fa5fccb2899f73413b732e0)
        #5 0x7f51ddd994da  (/usr/lib/x86_64-linux-gnu/ (BuildId: 1106af37206701c77fa5fccb2899f73413b732e0)
        #6 0x7f51ddd993da  (/usr/lib/x86_64-linux-gnu/ (BuildId: 1106af37206701c77fa5fccb2899f73413b732e0)
        #7 0x7f52459da608 in start_thread /build/glibc-SzIz7B/glibc-2.31/nptl/pthread_create.c:477:8
        #8 0x7f52455a1132 in __clone /build/glibc-SzIz7B/glibc-2.31/misc/../sysdeps/unix/sysv/linux/x86_64/clone.S:95
    0x7f503c3cf800 is located 0 bytes inside of 2147483648-byte region [0x7f503c3cf800,0x7f50bc3cf800)
    allocated by thread T47 (Compositor) here:
        #0 0x5570c1f45e67 in __interceptor_posix_memalign /builds/worker/fetches/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:145:3
        #1 0x7f51ddf8e5e7  (/usr/lib/x86_64-linux-gnu/ (BuildId: 1106af37206701c77fa5fccb2899f73413b732e0)
    Thread T178 created by T47 (Compositor) here:
        #0 0x5570c1f2eaec in __interceptor_pthread_create /builds/worker/fetches/llvm-project/compiler-rt/lib/asan/asan_interceptors.cpp:208:3
        #1 0x7f51ddd9b1ed  (/usr/lib/x86_64-linux-gnu/ (BuildId: 1106af37206701c77fa5fccb2899f73413b732e0)
    Thread T47 (Compositor) created by T0 here:
        #0 0x5570c1f2eaec in __interceptor_pthread_create /builds/worker/fetches/llvm-project/compiler-rt/lib/asan/asan_interceptors.cpp:208:3
        #1 0x7f524508c62c in _PR_CreateThread /gecko/nsprpub/pr/src/pthreads/ptthread.c:458:14
        #2 0x7f524507d9ce in PR_CreateThread /gecko/nsprpub/pr/src/pthreads/ptthread.c:533:12
        #3 0x7f521f7f1435 in nsThread::Init(nsTSubstring<char> const&) /gecko/xpcom/threads/nsThread.cpp:604:18
        #4 0x7f521f7fdbdf in nsThreadManager::NewNamedThread(nsTSubstring<char> const&, unsigned int, nsIThread**) /gecko/xpcom/threads/nsThreadManager.cpp:534:12
        #5 0x7f521f8099b1 in NS_NewNamedThread(nsTSubstring<char> const&, nsIThread**, already_AddRefed<nsIRunnable>, unsigned int) /gecko/xpcom/threads/nsThreadUtils.cpp:161:57
        #6 0x7f5221d21a82 in NS_NewNamedThread<11UL> /builds/worker/workspace/obj-build/dist/include/nsThreadUtils.h:74:10
        #7 0x7f5221d21a82 in mozilla::layers::CompositorThreadHolder::CreateCompositorThread() /gecko/gfx/layers/ipc/CompositorThread.cpp:66:17
        #8 0x7f5221d21e71 in CompositorThreadHolder /gecko/gfx/layers/ipc/CompositorThread.cpp:40:25
        #9 0x7f5221d21e71 in mozilla::layers::CompositorThreadHolder::Start() /gecko/gfx/layers/ipc/CompositorThread.cpp:109:33
        #10 0x7f5221f7a80b in gfxPlatform::Init() /gecko/gfx/thebes/gfxPlatform.cpp:956:3
        #11 0x7f5221f7e176 in GetPlatform /gecko/gfx/thebes/gfxPlatform.cpp:466:5
        #12 0x7f5221f7e176 in gfxPlatform::InitializeCMS() /gecko/gfx/thebes/gfxPlatform.cpp:2089:9
        #13 0x7f5227d0b7b4 in EnsureCMSInitialized /builds/worker/workspace/obj-build/dist/include/gfxPlatform.h:982:7
        #14 0x7f5227d0b7b4 in gfxPlatform::GetCMSMode() /builds/worker/workspace/obj-build/dist/include/gfxPlatform.h:526:5
        #15 0x7f5227d0b01d in nsXPLookAndFeel::GetColorValue(mozilla::StyleSystemColor, mozilla::ColorScheme, mozilla::LookAndFeel::UseStandins, unsigned int&) /gecko/widget/nsXPLookAndFeel.cpp:879:9
        #16 0x7f5227d0f17e in mozilla::LookAndFeel::GetColor(mozilla::StyleSystemColor, mozilla::ColorScheme, mozilla::LookAndFeel::UseStandins) /gecko/widget/nsXPLookAndFeel.cpp:1279:47
        #17 0x7f5227c7bcfc in Color /builds/worker/workspace/obj-build/dist/include/mozilla/LookAndFeel.h:444:12
        #18 0x7f5227c7bcfc in ThemedAccentColor /gecko/widget/ThemeColors.cpp:88:37
        #19 0x7f5227c7bcfc in mozilla::widget::ThemeColors::RecomputeAccentColors() /gecko/widget/ThemeColors.cpp:197:20
        #20 0x7f5227c7b945 in mozilla::widget::Theme::LookAndFeelChanged() /gecko/widget/Theme.cpp:180:3
        #21 0x7f5227d093f6 in nsXPLookAndFeel::GetInstance() /gecko/widget/nsXPLookAndFeel.cpp:361:3
        #22 0x7f5227d0fb1d in mozilla::LookAndFeel::GetThemeInfo(nsTSubstring<char>&) /gecko/widget/nsXPLookAndFeel.cpp:1392:3
        #23 0x7f521f654f0a in nsSystemInfo::Init() /gecko/xpcom/base/nsSystemInfo.cpp:1047:5
        #24 0x7f521f765627 in mozilla::xpcom::CreateInstanceImpl(mozilla::xpcom::ModuleID, nsID const&, void**) /builds/worker/workspace/obj-build/xpcom/components/StaticComponents.cpp:8912:7
        #25 0x7f521f7a2780 in CreateInstance /gecko/xpcom/components/nsComponentManager.cpp:185:46
        #26 0x7f521f7a2780 in nsComponentManagerImpl::GetServiceLocked(mozilla::Maybe<mozilla::detail::BaseMonitorAutoLock<mozilla::Monitor> >&, (anonymous namespace)::EntryWrapper&, nsID const&, void**) /gecko/xpcom/components/nsComponentManager.cpp:1283:17
        #27 0x7f521f7a3228 in nsComponentManagerImpl::GetService(mozilla::xpcom::ModuleID, nsID const&, void**) /gecko/xpcom/components/nsComponentManager.cpp:1373:10
        #28 0x7f521f778b8d in mozilla::xpcom::GetServiceHelper::operator()(nsID const&, void**) const /builds/worker/workspace/obj-build/xpcom/components/StaticComponents.cpp:12207:50
        #29 0x7f521f60c5e1 in nsCOMPtr_base::assign_from_helper(nsCOMPtr_helper const&, nsID const&) /gecko/xpcom/base/nsCOMPtr.cpp:109:7
        #30 0x7f522120fd1f in nsCOMPtr /builds/worker/workspace/obj-build/dist/include/nsCOMPtr.h:999:5
        #31 0x7f522120fd1f in GetServiceImpl /gecko/js/xpconnect/src/JSServices.cpp:83:32
        #32 0x7f522120fd1f in GetService /gecko/js/xpconnect/src/JSServices.cpp:130:8
        #33 0x7f522120fd1f in xpc::Services_Resolve(JSContext*, JS::Handle<JSObject*>, JS::Handle<JS::PropertyKey>, bool*) /gecko/js/xpconnect/src/JSServices.cpp:153:25
        #34 0x7f522d1d8277 in CallResolveOp /gecko/js/src/vm/NativeObject-inl.h:640:8
        #35 0x7f522d1d8277 in NativeLookupOwnPropertyInline<js::CanGC, js::LookupResolveMode::CheckResolve> /gecko/js/src/vm/NativeObject-inl.h:760:14
        #36 0x7f522d1d8277 in NativeGetPropertyInline<js::CanGC> /gecko/js/src/vm/NativeObject.cpp:2136:10
        #37 0x7f522d1d8277 in js::NativeGetProperty(JSContext*, JS::Handle<js::NativeObject*>, JS::Handle<JS::Value>, JS::Handle<JS::PropertyKey>, JS::MutableHandle<JS::Value>) /gecko/js/src/vm/NativeObject.cpp:2184:10
        #38 0x7f522cef1b99 in GetProperty /gecko/js/src/vm/ObjectOperations-inl.h:120:10
        #39 0x7f522cef1b99 in js::GetProperty(JSContext*, JS::Handle<JSObject*>, JS::Handle<JS::Value>, js::PropertyName*, JS::MutableHandle<JS::Value>) /gecko/js/src/vm/ObjectOperations-inl.h:127:10
        #40 0x7f522e8c745b in js::GetProperty(JSContext*, JS::Handle<JS::Value>, JS::Handle<js::PropertyName*>, JS::MutableHandle<JS::Value>) /gecko/js/src/vm/Interpreter.cpp:4668:10
        #41 0x7f522e89fd64 in GetPropertyOperation /gecko/js/src/vm/Interpreter.cpp:203:10
        #42 0x7f522e89fd64 in Interpret(JSContext*, js::RunState&) /gecko/js/src/vm/Interpreter.cpp:2984:12
        #43 0x7f522e892101 in js::RunScript(JSContext*, js::RunState&) /gecko/js/src/vm/Interpreter.cpp:389:13
        #44 0x7f522e8c03cf in js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) /gecko/js/src/vm/Interpreter.cpp:539:13
        #45 0x7f522e8c1f5a in InternalCall /gecko/js/src/vm/Interpreter.cpp:574:10
        #46 0x7f522e8c1f5a in js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>, js::CallReason) /gecko/js/src/vm/Interpreter.cpp:605:8
        #47 0x7f522cff629c in JS_CallFunctionValue(JSContext*, JS::Handle<JSObject*>, JS::Handle<JS::Value>, JS::HandleValueArray const&, JS::MutableHandle<JS::Value>) /gecko/js/src/vm/CallAndConstruct.cpp:53:10
        #48 0x7f5221255915 in nsXPCWrappedJS::CallMethod(unsigned short, nsXPTMethodInfo const*, nsXPTCMiniVariant*) /gecko/js/xpconnect/src/XPCWrappedJSClass.cpp:981:17
        #49 0x7f521f846882 in PrepareAndDispatch /gecko/xpcom/reflect/xptcall/md/unix/xptcstubs_x86_64_linux.cpp:115:37
        #50 0x7f521f8455da in SharedStub xptcstubs_x86_64_linux.cpp
        #51 0x7f521f798ced in NS_CreateServicesFromCategory(char const*, nsISupports*, char const*, char16_t const*) /gecko/xpcom/components/nsCategoryManager.cpp:682:19
        #52 0x7f522cbbdf19 in nsXREDirProvider::DoStartup() /gecko/toolkit/xre/nsXREDirProvider.cpp:936:11
        #53 0x7f522cb9b160 in XREMain::XRE_mainRun() /gecko/toolkit/xre/nsAppRunner.cpp:5474:18
        #54 0x7f522cb9da15 in XREMain::XRE_main(int, char**, mozilla::BootstrapConfig const&) /gecko/toolkit/xre/nsAppRunner.cpp:5916:8
        #55 0x7f522cb9e753 in XRE_main(int, char**, mozilla::BootstrapConfig const&) /gecko/toolkit/xre/nsAppRunner.cpp:5983:21
        #56 0x5570c1f8374d in do_main /gecko/browser/app/nsBrowserApp.cpp:225:22
        #57 0x5570c1f8374d in main /gecko/browser/app/nsBrowserApp.cpp:397:16
        #58 0x7f52454a6082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16
    SUMMARY: AddressSanitizer: negative-size-param /builds/worker/fetches/llvm-project/compiler-rt/lib/asan/../sanitizer_common/ in __interceptor_memcpy
Attached file testcase.html
Group: core-security → gfx-core-security

A pernosco session for this issue can be found here.

The severity field is not set for this bug.
:jimb, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(jimb)
Severity: -- → S3
Flags: needinfo?(jimb)
Priority: -- → P2

The severity field for this bug is set to S3. However, the bug is flagged with the sec-high keyword.
:jimb, could you consider increasing the severity of this security bug?

For more information, please visit auto_nag documentation.

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

Here is the stack with driver symbols:

==51804==ERROR: AddressSanitizer: negative-size-param: (size=-2147483648)
error: address range table at offset 0x1c490 has a premature terminator entry at offset 0x1c4a0
error: address range table at offset 0x1c920 has a premature terminator entry at offset 0x1c930
    #0 0x56367df03cf5 in memcpy /builds/worker/fetches/llvm-project/compiler-rt/lib/asan/../sanitizer_common/
    #1 0x7f909b8643fc  /usr/include/bits/string_fortified.h:29:10
    #2 0x7f909b8643fc  /usr/src/debug/mesa-21.3.8-2.fc35.x86_64/redhat-linux-build/../src/gallium/auxiliary/util/u_surface.c:315:7
    #3 0x7f909b7d20f0 in handle_copy_buffer /usr/src/debug/mesa-21.3.8-2.fc35.x86_64/redhat-linux-build/../src/gallium/frontends/lavapipe/lvp_execute.c:2331:7
    #4 0x7f909b7d20f0 in lvp_execute_cmd_buffer /usr/src/debug/mesa-21.3.8-2.fc35.x86_64/redhat-linux-build/../src/gallium/frontends/lavapipe/lvp_execute.c:3695:10
    #5 0x7f909b7d3c92 in lvp_execute_cmds /usr/src/debug/mesa-21.3.8-2.fc35.x86_64/redhat-linux-build/../src/gallium/frontends/lavapipe/lvp_execute.c:3900:4
    #6 0x7f909b7c509b in queue_thread /usr/src/debug/mesa-21.3.8-2.fc35.x86_64/redhat-linux-build/../src/gallium/frontends/lavapipe/lvp_device.c:1361:7
    #7 0x7f909b806048  /usr/src/debug/mesa-21.3.8-2.fc35.x86_64/redhat-linux-build/../src/util/u_queue.c:313:10
    #8 0x7f909b805bda  /usr/src/debug/mesa-21.3.8-2.fc35.x86_64/redhat-linux-build/../include/c11/threads_posix.h:87:29
    #9 0x7f91bd538da1 in start_thread (/lib64/ (BuildId: 01f82f54071b54ae66314a217041af486242ae56)
    #10 0x7f91bd4d89df in __GI___clone3 (/lib64/ (BuildId: 01f82f54071b54ae66314a217041af486242ae56)

The bug is happening in the driver here:

The some internal copy is going on and the extents of the copy are stored in a pipe_box which is made of 32bit integers, see

we are trying to issue a copy of the size of the buffer which is 2147483648 (just enough to overflow int32_t).
It's a mesa bug, for sure but I think that it is safe to assume other drivers will make similar mistakes, so we should refuse any allocation size that that does not fit in 31 bits.

Also note that pipe_box's y and z are int16_t, so with driver at least we should not accept any allocation of image or 3d textures which can't fit their height and depth within 15 bits. Again I think that it would be reasonable to expect other drivers to mess up the same way, I also think that we should be much stricter than 31 bits because allowing webpages unreasonably large gpu allocations is a recipe for letting them bring the entire system down. For example in webrender we don't allow texture width and height to be larger than 16384 pixels and we don't allocate any texture larger than 500_000_000 bytes.

Assignee: nobody → nical.bugzilla

Comment on attachment 9281812 [details]
Bug 1770219 - Disallow large buffer allocations. r=jimb

Security Approval Request

  • How easily could an exploit be constructed based on the patch?: Difficult because one would need to enable webgpu which is currently preffed off by default.
  • Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?: No
  • Which older supported branches are affected by this flaw?: None.
  • If not all supported branches, which bug introduced the flaw?: None
  • Do you have backports for the affected branches?: No
  • If not, how different, hard to create, and risky will they be?:
  • How likely is this patch to cause regressions; how much testing does it need?: Very unlikely, it's a rather simple patch.
  • Is Android affected?: Yes
Attachment #9281812 - Flags: sec-approval?

Comment on attachment 9281812 [details]
Bug 1770219 - Disallow large buffer allocations. r=jimb

sec-approving early because we can land this when it's ready as webgpu is preffed off by default. The exception would be: please don't land it past last uplift.

Attachment #9281812 - Flags: sec-approval? → sec-approval+
Group: gfx-core-security → core-security-release
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 104 Branch

[Tracking Requested - why for this release]: While webgpu is off by default; this is a sec-high

This grafts cleanly to Beta, but not to the ESR branches. Not sure what the uplift plan was here, but I guess it'd probably make sense to at least get it onto ESR102 for hardening's sake given how early in its lifecycle we are?

Flags: needinfo?(nical.bugzilla)

Comment on attachment 9285070 [details]
Bug 1770219 - Disallow large buffer allocations (esr). r=jimb

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration:
  • User impact if declined: Potential security issue on some driver if webgpu is enabled by the user.

WebGPU is not enabled on ESR102 so the risk isn't very high. In addition the issue only affects some drivers (mesa for example). So I'll leave it up to you whether it's worth uplifting at all. It could ride along with other fixes but I wouldn't bother with making a release for it.

This version of the patch should build on top of esr102, For some reason I'm getting build errors in a completely different area of gecko (but no error in that code).

  • Fix Landed on Version:
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): it's a rather simple change, subset of what landed on central.
Flags: needinfo?(nical.bugzilla)
Attachment #9285070 - Flags: approval-mozilla-esr102?

The patch landed in nightly and beta is affected.
:nical, is this bug important enough to require an uplift?

  • If yes, please nominate the patch for beta approval.
  • If no, please set status-firefox103 to wontfix.

For more information, please visit auto_nag documentation.

Flags: needinfo?(nical.bugzilla)
Flags: needinfo?(nical.bugzilla)
QA Whiteboard: [post-critsmash-triage]
Flags: qe-verify-

Comment on attachment 9285070 [details]
Bug 1770219 - Disallow large buffer allocations (esr). r=jimb

Good belts and suspenders fix to take. Approved for 102.2esr.

Attachment #9285070 - Flags: approval-mozilla-esr102? → approval-mozilla-esr102+

Sorry about that. I updated the patch to align more with how the code works in esr. I also had to turn one of the errors into a crash which is still better than the potential security threat. I again had issues building gecko but I could build wgpu_bindings in isolation so this has a better chance of building properly.

Flags: needinfo?(nical.bugzilla)
Whiteboard: [bugmon:confirm] → [bugmon:confirm][adv-main104+r]
Whiteboard: [bugmon:confirm][adv-main104+r] → [bugmon:confirm][adv-main104+r][adv-esr102.2+r]
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.