1895951 - (CVE-2024-7528) AddressSanitizer: heap-use-after-free [@ mozilla::Result<mozilla::Ok, nsresult> mozilla::dom::indexedDB::Key::EncodeAsString<unsigned char>] with READ of size 1

Status: VERIFIED FIXED

(Core :: Storage: IndexedDB, defect, P1)

Description

[Jason Kratzer [:jkratzer]]

Testcase found while fuzzing mozilla-central rev ee7969730d0c (built with: --enable-debug --enable-fuzzing).

Testcase can be reproduced using the following commands:

$ pip install fuzzfetch grizzly-framework --upgrade
$ python -m fuzzfetch --build ee7969730d0c --debug --fuzzing  -n firefox
$ python -m grizzly.replay.bugzilla ./firefox/firefox <bugid>

AddressSanitizer: heap-use-after-free [@ mozilla::Result<mozilla::Ok, nsresult> mozilla::dom::indexedDB::Key::EncodeAsString<unsigned char>] with READ of size 1

    =================================================================
    ==518223==ERROR: AddressSanitizer: heap-use-after-free on address 0x529000389200 at pc 0x7a7eb08e0514 bp 0x7a7e8ecae5c0 sp 0x7a7e8ecae5b8
    READ of size 1 at 0x529000389200 thread T33
        #0 0x7a7eb08e0513 in mozilla::Result<mozilla::Ok, nsresult> mozilla::dom::indexedDB::Key::EncodeAsString<unsigned char>(mozilla::Span<unsigned char const, 18446744073709551615ul>, unsigned char) /dom/indexedDB/Key.cpp:720:20
        #1 0x7a7eb08de980 in mozilla::dom::indexedDB::Key::EncodeJSValInternal(JSContext*, JS::Handle<JS::Value>, unsigned char, unsigned short) /dom/indexedDB/Key.cpp:529:14
        #2 0x7a7eb08e4fa1 in EncodeJSVal /dom/indexedDB/Key.cpp:635:10
        #3 0x7a7eb08e4fa1 in mozilla::dom::indexedDB::Key::SetFromJSVal(JSContext*, JS::Handle<JS::Value>) /dom/indexedDB/Key.cpp:1023:17
        #4 0x7a7eb0960471 in mozilla::dom::IDBFactory::Cmp(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, mozilla::ErrorResult&) /dom/indexedDB/IDBFactory.cpp:537:19
        #5 0x7a7eab03c501 in mozilla::dom::IDBFactory_Binding::cmp(JSContext*, JS::Handle<JSObject*>, void*, JSJitMethodCallArgs const&) /builds/worker/workspace/obj-build/dom/bindings/./IDBFactoryBinding.cpp:419:39
        #6 0x7a7eacfbbe94 in bool mozilla::dom::binding_detail::GenericMethod<mozilla::dom::binding_detail::NormalThisPolicy, mozilla::dom::binding_detail::ThrowExceptions>(JSContext*, unsigned int, JS::Value*) /dom/bindings/BindingUtils.cpp:3268:13
        #7 0x7a7eb73d2721 in CallJSNative /js/src/vm/Interpreter.cpp:480:13
        #8 0x7a7eb73d2721 in js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) /js/src/vm/Interpreter.cpp:574:12
        #9 0x7a7eb73f96fe in InternalCall /js/src/vm/Interpreter.cpp:641:10
        #10 0x7a7eb73f96fe in CallFromStack /js/src/vm/Interpreter.cpp:646:10
        #11 0x7a7eb73f96fe in js::Interpret(JSContext*, js::RunState&) /js/src/vm/Interpreter.cpp:3071:16
        #12 0x7a7eb73d1429 in MaybeEnterInterpreterTrampoline /js/src/vm/Interpreter.cpp:394:10
        #13 0x7a7eb73d1429 in js::RunScript(JSContext*, js::RunState&) /js/src/vm/Interpreter.cpp:452:13
        #14 0x7a7eb73d28ea in js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) /js/src/vm/Interpreter.cpp:606:13
        #15 0x7a7eb73d4a16 in InternalCall /js/src/vm/Interpreter.cpp:641:10
        #16 0x7a7eb73d4a16 in js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>, js::CallReason) /js/src/vm/Interpreter.cpp:673:8
        #17 0x7a7eb759adcb in JS::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, JS::HandleValueArray const&, JS::MutableHandle<JS::Value>) /js/src/vm/CallAndConstruct.cpp:119:10
        #18 0x7a7eac1953cb in mozilla::dom::SchedulerPostTaskCallback::Call(mozilla::dom::BindingCallContext&, JS::Handle<JS::Value>, JS::MutableHandle<JS::Value>, mozilla::ErrorResult&) /builds/worker/workspace/obj-build/dom/bindings/./WebTaskSchedulingBinding.cpp:76:8
        #19 0x7a7eb1dffd43 in Call /builds/worker/workspace/obj-build/dist/include/mozilla/dom/WebTaskSchedulingBinding.h:114:12
        #20 0x7a7eb1dffd43 in mozilla::dom::WebTask::Run() /dom/webscheduling/WebTaskScheduler.cpp:106:29
        #21 0x7a7eb1e055ae in mozilla::dom::WebTaskWorkerRunnable::WorkerRun(JSContext*, mozilla::dom::WorkerPrivate*) /dom/webscheduling/WebTaskSchedulerWorker.cpp:31:13
        #22 0x7a7eb12fba00 in mozilla::dom::WorkerThreadRunnable::Run() /dom/workers/WorkerRunnable.cpp:439:12
        #23 0x7a7ea681eb76 in nsThread::ProcessNextEvent(bool, bool*) /xpcom/threads/nsThread.cpp:1193:16
        #24 0x7a7ea682c44a in NS_ProcessNextEvent(nsIThread*, bool) /xpcom/threads/nsThreadUtils.cpp:480:10
        #25 0x7a7eb12d8f72 in mozilla::dom::WorkerPrivate::DoRunLoop(JSContext*) /dom/workers/WorkerPrivate.cpp:3468:7
        #26 0x7a7eb129e4a8 in mozilla::dom::workerinternals::(anonymous namespace)::WorkerThreadPrimaryRunnable::Run() /dom/workers/RuntimeService.cpp:2130:42
        #27 0x7a7ea681eb76 in nsThread::ProcessNextEvent(bool, bool*) /xpcom/threads/nsThread.cpp:1193:16
        #28 0x7a7ea682c44a in NS_ProcessNextEvent(nsIThread*, bool) /xpcom/threads/nsThreadUtils.cpp:480:10
        #29 0x7a7ea85477d1 in mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*) /ipc/glue/MessagePump.cpp:300:20
        #30 0x7a7ea83649ca in RunInternal /ipc/chromium/src/base/message_loop.cc:370:10
        #31 0x7a7ea83649ca in RunHandler /ipc/chromium/src/base/message_loop.cc:363:3
        #32 0x7a7ea83649ca in MessageLoop::Run() /ipc/chromium/src/base/message_loop.cc:345:3
        #33 0x7a7ea6815390 in nsThread::ThreadFunc(void*) /xpcom/threads/nsThread.cpp:370:10
        #34 0x7a7ecf3eb11f in _pt_root /nsprpub/pr/src/pthreads/ptthread.c:201:5
        #35 0x5e1e1829dd9a in asan_thread_start(void*) /builds/worker/fetches/llvm-project/compiler-rt/lib/asan/asan_interceptors.cpp:225:31
        #36 0x7a7ecfbf2ac2 in start_thread nptl/pthread_create.c:442:8
        #37 0x7a7ecfc8484f  misc/../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
    
    0x529000389200 is located 0 bytes inside of 16256-byte region [0x529000389200,0x52900038d180)
    freed by thread T33 here:
        #0 0x5e1e182a1656 in free /builds/worker/fetches/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:52:3
        #1 0x7a7eb7a9f29a in js_free /builds/worker/workspace/obj-build/dist/include/js/Utility.h:418:3
        #2 0x7a7eb7a9f29a in js::TypedArrayObject::ensureHasBuffer(JSContext*, JS::Handle<js::TypedArrayObject*>) /js/src/vm/TypedArrayObject.cpp:169:5
        #3 0x7a7eb754b099 in js::ArrayBufferViewObject::ensureBufferObject(JSContext*, JS::Handle<js::ArrayBufferViewObject*>) /js/src/vm/ArrayBufferViewObject.cpp:112:10
        #4 0x7a7eb754d188 in JS_GetArrayBufferViewBuffer(JSContext*, JS::Handle<JSObject*>, bool*) /js/src/vm/ArrayBufferViewObject.cpp:462:9
        #5 0x7a7eb08de424 in IsDetachedBuffer /dom/indexedDB/Key.cpp:111:14
        #6 0x7a7eb08de424 in GetByteSpanFromJSBufferSource /dom/indexedDB/Key.cpp:173:7
        #7 0x7a7eb08de424 in mozilla::dom::indexedDB::Key::EncodeJSValInternal(JSContext*, JS::Handle<JS::Value>, unsigned char, unsigned short) /dom/indexedDB/Key.cpp:520:18
        #8 0x7a7eb08e4fa1 in EncodeJSVal /dom/indexedDB/Key.cpp:635:10
        #9 0x7a7eb08e4fa1 in mozilla::dom::indexedDB::Key::SetFromJSVal(JSContext*, JS::Handle<JS::Value>) /dom/indexedDB/Key.cpp:1023:17
        #10 0x7a7eb0960471 in mozilla::dom::IDBFactory::Cmp(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, mozilla::ErrorResult&) /dom/indexedDB/IDBFactory.cpp:537:19
        #11 0x7a7eab03c501 in mozilla::dom::IDBFactory_Binding::cmp(JSContext*, JS::Handle<JSObject*>, void*, JSJitMethodCallArgs const&) /builds/worker/workspace/obj-build/dom/bindings/./IDBFactoryBinding.cpp:419:39
        #12 0x7a7eacfbbe94 in bool mozilla::dom::binding_detail::GenericMethod<mozilla::dom::binding_detail::NormalThisPolicy, mozilla::dom::binding_detail::ThrowExceptions>(JSContext*, unsigned int, JS::Value*) /dom/bindings/BindingUtils.cpp:3268:13
        #13 0x7a7eb73d2721 in CallJSNative /js/src/vm/Interpreter.cpp:480:13
        #14 0x7a7eb73d2721 in js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) /js/src/vm/Interpreter.cpp:574:12
        #15 0x7a7eb73f96fe in InternalCall /js/src/vm/Interpreter.cpp:641:10
        #16 0x7a7eb73f96fe in CallFromStack /js/src/vm/Interpreter.cpp:646:10
        #17 0x7a7eb73f96fe in js::Interpret(JSContext*, js::RunState&) /js/src/vm/Interpreter.cpp:3071:16
        #18 0x7a7eb73d1429 in MaybeEnterInterpreterTrampoline /js/src/vm/Interpreter.cpp:394:10
        #19 0x7a7eb73d1429 in js::RunScript(JSContext*, js::RunState&) /js/src/vm/Interpreter.cpp:452:13
        #20 0x7a7eb73d28ea in js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) /js/src/vm/Interpreter.cpp:606:13
        #21 0x7a7eb73d4a16 in InternalCall /js/src/vm/Interpreter.cpp:641:10
        #22 0x7a7eb73d4a16 in js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>, js::CallReason) /js/src/vm/Interpreter.cpp:673:8
        #23 0x7a7eb759adcb in JS::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, JS::HandleValueArray const&, JS::MutableHandle<JS::Value>) /js/src/vm/CallAndConstruct.cpp:119:10
        #24 0x7a7eac1953cb in mozilla::dom::SchedulerPostTaskCallback::Call(mozilla::dom::BindingCallContext&, JS::Handle<JS::Value>, JS::MutableHandle<JS::Value>, mozilla::ErrorResult&) /builds/worker/workspace/obj-build/dom/bindings/./WebTaskSchedulingBinding.cpp:76:8
        #25 0x7a7eb1dffd43 in Call /builds/worker/workspace/obj-build/dist/include/mozilla/dom/WebTaskSchedulingBinding.h:114:12
        #26 0x7a7eb1dffd43 in mozilla::dom::WebTask::Run() /dom/webscheduling/WebTaskScheduler.cpp:106:29
        #27 0x7a7eb1e055ae in mozilla::dom::WebTaskWorkerRunnable::WorkerRun(JSContext*, mozilla::dom::WorkerPrivate*) /dom/webscheduling/WebTaskSchedulerWorker.cpp:31:13
        #28 0x7a7eb12fba00 in mozilla::dom::WorkerThreadRunnable::Run() /dom/workers/WorkerRunnable.cpp:439:12
        #29 0x7a7ea681eb76 in nsThread::ProcessNextEvent(bool, bool*) /xpcom/threads/nsThread.cpp:1193:16
        #30 0x7a7ea682c44a in NS_ProcessNextEvent(nsIThread*, bool) /xpcom/threads/nsThreadUtils.cpp:480:10
        #31 0x7a7eb12d8f72 in mozilla::dom::WorkerPrivate::DoRunLoop(JSContext*) /dom/workers/WorkerPrivate.cpp:3468:7
        #32 0x7a7eb129e4a8 in mozilla::dom::workerinternals::(anonymous namespace)::WorkerThreadPrimaryRunnable::Run() /dom/workers/RuntimeService.cpp:2130:42
        #33 0x7a7ea681eb76 in nsThread::ProcessNextEvent(bool, bool*) /xpcom/threads/nsThread.cpp:1193:16
        #34 0x7a7ea682c44a in NS_ProcessNextEvent(nsIThread*, bool) /xpcom/threads/nsThreadUtils.cpp:480:10
        #35 0x7a7ea85477d1 in mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*) /ipc/glue/MessagePump.cpp:300:20
        #36 0x7a7ea83649ca in RunInternal /ipc/chromium/src/base/message_loop.cc:370:10
        #37 0x7a7ea83649ca in RunHandler /ipc/chromium/src/base/message_loop.cc:363:3
        #38 0x7a7ea83649ca in MessageLoop::Run() /ipc/chromium/src/base/message_loop.cc:345:3
        #39 0x7a7ea6815390 in nsThread::ThreadFunc(void*) /xpcom/threads/nsThread.cpp:370:10
        #40 0x7a7ecf3eb11f in _pt_root /nsprpub/pr/src/pthreads/ptthread.c:201:5
        #41 0x5e1e1829dd9a in asan_thread_start(void*) /builds/worker/fetches/llvm-project/compiler-rt/lib/asan/asan_interceptors.cpp:225:31
    
    previously allocated by thread T33 here:
        #0 0x5e1e182a1a38 in calloc /builds/worker/fetches/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:77:3
        #1 0x7a7eb8524bac in js_arena_calloc /builds/worker/workspace/obj-build/dist/include/js/Utility.h:387:10
        #2 0x7a7eb8524bac in js_pod_arena_calloc<unsigned char> /builds/worker/workspace/obj-build/dist/include/js/Utility.h:601:26
        #3 0x7a7eb8524bac in maybe_pod_arena_calloc<unsigned char> /js/src/vm/MallocProvider.h:66:12
        #4 0x7a7eb8524bac in unsigned char* js::MallocProvider<JS::Zone>::pod_arena_calloc<unsigned char>(unsigned long, unsigned long) /js/src/vm/MallocProvider.h:163:12
        #5 0x7a7eb8524e59 in allocateZeroedBuffer /js/src/gc/Nursery.cpp:766:24
        #6 0x7a7eb8524e59 in js::Nursery::allocateZeroedBuffer(js::gc::Cell*, unsigned long, unsigned long) /js/src/gc/Nursery.cpp:779:7
        #7 0x7a7eb7aa42e9 in makeTypedArrayWithTemplate /js/src/vm/TypedArrayObject.cpp:1010:27
        #8 0x7a7eb7aa42e9 in js::NewTypedArrayWithTemplateAndLength(JSContext*, JS::Handle<JSObject*>, int) /js/src/vm/TypedArrayObject.cpp:1207:5
        #9 0x3e86e7743b9e  ([anon:js-executable-memory]+0x14b9e)
        #10 0x3e86e779fcff  ([anon:js-executable-memory]+0xcff)
        #11 0x3e86e779f62d  ([anon:js-executable-memory]+0x62d)
        #12 0x3e86e773f4e5  ([anon:js-executable-memory]+0x104e5)
        #13 0x7a7eb9294a5f in EnterJit /js/src/jit/Jit.cpp:115:5
        #14 0x7a7eb9294a5f in js::jit::MaybeEnterJit(JSContext*, js::RunState&) /js/src/jit/Jit.cpp:261:10
        #15 0x7a7eb73d114d in js::RunScript(JSContext*, js::RunState&) /js/src/vm/Interpreter.cpp:442:32
        #16 0x7a7eb73d28ea in js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) /js/src/vm/Interpreter.cpp:606:13
        #17 0x7a7eb73d4a16 in InternalCall /js/src/vm/Interpreter.cpp:641:10
        #18 0x7a7eb73d4a16 in js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>, js::CallReason) /js/src/vm/Interpreter.cpp:673:8
        #19 0x7a7eb759adcb in JS::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, JS::HandleValueArray const&, JS::MutableHandle<JS::Value>) /js/src/vm/CallAndConstruct.cpp:119:10
        #20 0x7a7eac988f62 in mozilla::dom::EventHandlerNonNull::Call(mozilla::dom::BindingCallContext&, JS::Handle<JS::Value>, mozilla::dom::Event&, JS::MutableHandle<JS::Value>, mozilla::ErrorResult&) /builds/worker/workspace/obj-build/dom/bindings/./EventHandlerBinding.cpp:65:37
        #21 0x7a7eade9fed2 in void mozilla::dom::EventHandlerNonNull::Call<nsCOMPtr<mozilla::dom::EventTarget>>(nsCOMPtr<mozilla::dom::EventTarget> const&, mozilla::dom::Event&, JS::MutableHandle<JS::Value>, mozilla::ErrorResult&, char const*, mozilla::dom::CallbackObject::ExceptionHandling, JS::Realm*) /builds/worker/workspace/obj-build/dist/include/mozilla/dom/EventHandlerBinding.h:82:12
        #22 0x7a7eade9d926 in mozilla::JSEventHandler::HandleEvent(mozilla::dom::Event*) /dom/events/JSEventHandler.cpp:199:12
        #23 0x7a7eade48f69 in mozilla::EventListenerManager::HandleEventSingleListener(mozilla::EventListenerManager::Listener*, nsAtom*, mozilla::WidgetEvent*, mozilla::dom::Event*, mozilla::dom::EventTarget*, bool) /dom/events/EventListenerManager.cpp:1313:22
        #24 0x7a7eade4b9aa in mozilla::EventListenerManager::HandleEventWithListenerArray(mozilla::EventListenerManager::ListenerArray*, nsAtom*, mozilla::EventMessage, nsPresContext*, mozilla::WidgetEvent*, mozilla::dom::Event**, mozilla::dom::EventTarget*, bool) /dom/events/EventListenerManager.cpp:1630:12
        #25 0x7a7eade4a3e6 in mozilla::EventListenerManager::HandleEventInternal(nsPresContext*, mozilla::WidgetEvent*, mozilla::dom::Event**, mozilla::dom::EventTarget*, nsEventStatus*, bool) /dom/events/EventListenerManager.cpp:1527:35
        #26 0x7a7eade2d872 in mozilla::EventTargetChainItem::HandleEvent(mozilla::EventChainPostVisitor&, mozilla::ELMCreationDetector&) /dom/events/EventDispatcher.cpp:365:17
        #27 0x7a7eade2af07 in mozilla::EventTargetChainItem::HandleEventTargetChain(nsTArray<mozilla::EventTargetChainItem>&, mozilla::EventChainPostVisitor&, mozilla::EventDispatchingCallback*, mozilla::ELMCreationDetector&) /dom/events/EventDispatcher.cpp:606:16
        #28 0x7a7eade32824 in mozilla::EventDispatcher::Dispatch(mozilla::dom::EventTarget*, nsPresContext*, mozilla::WidgetEvent*, mozilla::dom::Event*, nsEventStatus*, mozilla::EventDispatchingCallback*, nsTArray<mozilla::dom::EventTarget*>*) /dom/events/EventDispatcher.cpp:1221:11
        #29 0x7a7eade3bab8 in mozilla::EventDispatcher::DispatchDOMEvent(mozilla::dom::EventTarget*, mozilla::WidgetEvent*, mozilla::dom::Event*, nsPresContext*, nsEventStatus*) /dom/events/EventDispatcher.cpp
        #30 0x7a7eaddc02ce in mozilla::DOMEventTargetHelper::DispatchEvent(mozilla::dom::Event&, mozilla::dom::CallerType, mozilla::ErrorResult&) /dom/events/DOMEventTargetHelper.cpp:148:17
        #31 0x7a7eade5cd22 in mozilla::dom::EventTarget::DispatchEvent(mozilla::dom::Event&) /dom/events/EventTarget.cpp:214:13
        #32 0x7a7eb1265107 in mozilla::dom::MessageEventRunnable::DispatchDOMEvent(JSContext*, mozilla::dom::WorkerPrivate*, mozilla::DOMEventTargetHelper*, bool) /dom/workers/MessageEventRunnable.cpp:79:12
        #33 0x7a7eb12fba00 in mozilla::dom::WorkerThreadRunnable::Run() /dom/workers/WorkerRunnable.cpp:439:12
        #34 0x7a7ea681eb76 in nsThread::ProcessNextEvent(bool, bool*) /xpcom/threads/nsThread.cpp:1193:16
        #35 0x7a7ea682c44a in NS_ProcessNextEvent(nsIThread*, bool) /xpcom/threads/nsThreadUtils.cpp:480:10
        #36 0x7a7eb12d8f72 in mozilla::dom::WorkerPrivate::DoRunLoop(JSContext*) /dom/workers/WorkerPrivate.cpp:3468:7
    
    Thread T33 created by T0 (Isolated Web Co) here:
        #0 0x5e1e1828753d in pthread_create /builds/worker/fetches/llvm-project/compiler-rt/lib/asan/asan_interceptors.cpp:237:3
        #1 0x7a7ecf3d9844 in _PR_CreateThread /nsprpub/pr/src/pthreads/ptthread.c:458:14
        #2 0x7a7ecf3c743e in PR_CreateThread /nsprpub/pr/src/pthreads/ptthread.c:533:12
        #3 0x7a7ea6818fd9 in nsThread::Init(nsTSubstring<char> const&) /xpcom/threads/nsThread.cpp:620:20
        #4 0x7a7eb130ebea in mozilla::dom::WorkerThread::Create(mozilla::dom::WorkerThreadFriendKey const&) /dom/workers/WorkerThread.cpp:109:7
        #5 0x7a7eb126d217 in mozilla::dom::workerinternals::RuntimeService::ScheduleWorker(mozilla::dom::WorkerPrivate&) /dom/workers/RuntimeService.cpp:1328:37
        #6 0x7a7eb126b9f0 in mozilla::dom::workerinternals::RuntimeService::RegisterWorker(mozilla::dom::WorkerPrivate&) /dom/workers/RuntimeService.cpp:1210:19
        #7 0x7a7eb12d0867 in mozilla::dom::WorkerPrivate::Constructor(JSContext*, nsTSubstring<char16_t> const&, bool, mozilla::dom::WorkerKind, mozilla::dom::RequestCredentials, mozilla::dom::WorkerType, nsTSubstring<char16_t> const&, nsTSubstring<char> const&, mozilla::dom::WorkerLoadInfo*, mozilla::ErrorResult&, nsTString<char16_t>, std::function<void (bool)>&&, std::function<void ()>&&) /dom/workers/WorkerPrivate.cpp:2709:24
        #8 0x7a7eb128b187 in mozilla::dom::Worker::Constructor(mozilla::dom::GlobalObject const&, nsTSubstring<char16_t> const&, mozilla::dom::WorkerOptions const&, mozilla::ErrorResult&) /dom/workers/Worker.cpp:48:41
        #9 0x7a7eac539b37 in mozilla::dom::Worker_Binding::_constructor(JSContext*, unsigned int, JS::Value*) /builds/worker/workspace/obj-build/dom/bindings/./WorkerBinding.cpp:1140:52
        #10 0x7a7eb73d5654 in CallJSNative /js/src/vm/Interpreter.cpp:480:13
        #11 0x7a7eb73d5654 in CallJSNativeConstructor /js/src/vm/Interpreter.cpp:496:8
        #12 0x7a7eb73d5654 in InternalConstruct(JSContext*, js::AnyConstructArgs const&, js::CallReason) /js/src/vm/Interpreter.cpp:702:14
        #13 0x7a7eb73f9674 in ConstructFromStack /js/src/vm/Interpreter.cpp:749:10
        #14 0x7a7eb73f9674 in js::Interpret(JSContext*, js::RunState&) /js/src/vm/Interpreter.cpp:3056:16
        #15 0x7a7eb73d1429 in MaybeEnterInterpreterTrampoline /js/src/vm/Interpreter.cpp:394:10
        #16 0x7a7eb73d1429 in js::RunScript(JSContext*, js::RunState&) /js/src/vm/Interpreter.cpp:452:13
        #17 0x7a7eb73d28ea in js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) /js/src/vm/Interpreter.cpp:606:13
        #18 0x7a7eb73d4a16 in InternalCall /js/src/vm/Interpreter.cpp:641:10
        #19 0x7a7eb73d4a16 in js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>, js::CallReason) /js/src/vm/Interpreter.cpp:673:8
        #20 0x7a7eb759adcb in JS::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, JS::HandleValueArray const&, JS::MutableHandle<JS::Value>) /js/src/vm/CallAndConstruct.cpp:119:10
        #21 0x7a7eac98f33f in mozilla::dom::EventListener::HandleEvent(mozilla::dom::BindingCallContext&, JS::Handle<JS::Value>, mozilla::dom::Event&, mozilla::ErrorResult&) /builds/worker/workspace/obj-build/dom/bindings/./EventListenerBinding.cpp:62:8
        #22 0x7a7eade49a57 in void mozilla::dom::EventListener::HandleEvent<mozilla::dom::EventTarget*>(mozilla::dom::EventTarget* const&, mozilla::dom::Event&, mozilla::ErrorResult&, char const*, mozilla::dom::CallbackObject::ExceptionHandling, JS::Realm*) /builds/worker/workspace/obj-build/dist/include/mozilla/dom/EventListenerBinding.h:65:12
        #23 0x7a7eade48ecf in mozilla::EventListenerManager::HandleEventSingleListener(mozilla::EventListenerManager::Listener*, nsAtom*, mozilla::WidgetEvent*, mozilla::dom::Event*, mozilla::dom::EventTarget*, bool) /dom/events/EventListenerManager.cpp:1307:43
        #24 0x7a7eade4b9aa in mozilla::EventListenerManager::HandleEventWithListenerArray(mozilla::EventListenerManager::ListenerArray*, nsAtom*, mozilla::EventMessage, nsPresContext*, mozilla::WidgetEvent*, mozilla::dom::Event**, mozilla::dom::EventTarget*, bool) /dom/events/EventListenerManager.cpp:1630:12
        #25 0x7a7eade4a3e6 in mozilla::EventListenerManager::HandleEventInternal(nsPresContext*, mozilla::WidgetEvent*, mozilla::dom::Event**, mozilla::dom::EventTarget*, nsEventStatus*, bool) /dom/events/EventListenerManager.cpp:1527:35
        #26 0x7a7eade2d872 in mozilla::EventTargetChainItem::HandleEvent(mozilla::EventChainPostVisitor&, mozilla::ELMCreationDetector&) /dom/events/EventDispatcher.cpp:365:17
        #27 0x7a7eade2af07 in mozilla::EventTargetChainItem::HandleEventTargetChain(nsTArray<mozilla::EventTargetChainItem>&, mozilla::EventChainPostVisitor&, mozilla::EventDispatchingCallback*, mozilla::ELMCreationDetector&) /dom/events/EventDispatcher.cpp:606:16
        #28 0x7a7eade32824 in mozilla::EventDispatcher::Dispatch(mozilla::dom::EventTarget*, nsPresContext*, mozilla::WidgetEvent*, mozilla::dom::Event*, nsEventStatus*, mozilla::EventDispatchingCallback*, nsTArray<mozilla::dom::EventTarget*>*) /dom/events/EventDispatcher.cpp:1221:11
        #29 0x7a7eade3bab8 in mozilla::EventDispatcher::DispatchDOMEvent(mozilla::dom::EventTarget*, mozilla::WidgetEvent*, mozilla::dom::Event*, nsPresContext*, nsEventStatus*) /dom/events/EventDispatcher.cpp
        #30 0x7a7eaac6345b in nsINode::DispatchEvent(mozilla::dom::Event&, mozilla::dom::CallerType, mozilla::ErrorResult&) /dom/base/nsINode.cpp:1430:17
        #31 0x7a7eaa31e565 in nsContentUtils::DispatchEvent(mozilla::dom::Document*, mozilla::dom::EventTarget*, nsTSubstring<char16_t> const&, mozilla::CanBubble, mozilla::Cancelable, mozilla::Composed, mozilla::Trusted, bool*, mozilla::ChromeOnlyDispatch) /dom/base/nsContentUtils.cpp:4796:29
        #32 0x7a7eaa31e214 in nsContentUtils::DispatchTrustedEvent(mozilla::dom::Document*, mozilla::dom::EventTarget*, nsTSubstring<char16_t> const&, mozilla::CanBubble, mozilla::Cancelable, mozilla::Composed, bool*) /dom/base/nsContentUtils.cpp:4762:10
        #33 0x7a7eaa7b2c6f in mozilla::dom::Document::DispatchContentLoadedEvents() /dom/base/Document.cpp:8073:3
        #34 0x7a7eaa8ef0bb in operator()<> /builds/worker/workspace/obj-build/dist/include/nsThreadUtils.h:1085:18
        #35 0x7a7eaa8ef0bb in __invoke_impl<void, (lambda at /builds/worker/workspace/obj-build/dist/include/nsThreadUtils.h:1084:9)> /builds/worker/fetches/sysroot-x86_64-linux-gnu/usr/lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/bits/invoke.h:60:14
        #36 0x7a7eaa8ef0bb in __invoke<(lambda at /builds/worker/workspace/obj-build/dist/include/nsThreadUtils.h:1084:9)> /builds/worker/fetches/sysroot-x86_64-linux-gnu/usr/lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/bits/invoke.h:95:14
        #37 0x7a7eaa8ef0bb in __apply_impl<(lambda at /builds/worker/workspace/obj-build/dist/include/nsThreadUtils.h:1084:9), std::tuple<> &> /builds/worker/fetches/sysroot-x86_64-linux-gnu/usr/lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/tuple:1678:14
        #38 0x7a7eaa8ef0bb in apply<(lambda at /builds/worker/workspace/obj-build/dist/include/nsThreadUtils.h:1084:9), std::tuple<> &> /builds/worker/fetches/sysroot-x86_64-linux-gnu/usr/lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/tuple:1687:14
        #39 0x7a7eaa8ef0bb in apply<mozilla::dom::Document, void (mozilla::dom::Document::*)()> /builds/worker/workspace/obj-build/dist/include/nsThreadUtils.h:1083:12
        #40 0x7a7eaa8ef0bb in mozilla::detail::RunnableMethodImpl<mozilla::dom::Document*, void (mozilla::dom::Document::*)(), true, (mozilla::RunnableKind)0>::Run() /builds/worker/workspace/obj-build/dist/include/nsThreadUtils.h:1134:13
        #41 0x7a7ea67ee6fa in mozilla::RunnableTask::Run() /xpcom/threads/TaskController.cpp:580:16
        #42 0x7a7ea67d3f8b in mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&) /xpcom/threads/TaskController.cpp:907:26
        #43 0x7a7ea67d0b68 in mozilla::TaskController::ExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&) /xpcom/threads/TaskController.cpp:730:15
        #44 0x7a7ea67d1269 in mozilla::TaskController::ProcessPendingMTTask(bool) /xpcom/threads/TaskController.cpp:516:36
        #45 0x7a7ea67f67f1 in operator() /xpcom/threads/TaskController.cpp:234:37
        #46 0x7a7ea67f67f1 in mozilla::detail::RunnableFunction<mozilla::TaskController::TaskController()::$_0>::Run() /xpcom/threads/nsThreadUtils.h:548:5
        #47 0x7a7ea681e78f in nsThread::ProcessNextEvent(bool, bool*) /xpcom/threads/nsThread.cpp:1199:16
        #48 0x7a7ea682c44a in NS_ProcessNextEvent(nsIThread*, bool) /xpcom/threads/nsThreadUtils.cpp:480:10
        #49 0x7a7ea854601e in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) /ipc/glue/MessagePump.cpp:85:21
        #50 0x7a7ea83649ca in RunInternal /ipc/chromium/src/base/message_loop.cc:370:10
        #51 0x7a7ea83649ca in RunHandler /ipc/chromium/src/base/message_loop.cc:363:3
        #52 0x7a7ea83649ca in MessageLoop::Run() /ipc/chromium/src/base/message_loop.cc:345:3
        #53 0x7a7eb1f529a9 in nsBaseAppShell::Run() /widget/nsBaseAppShell.cpp:148:27
        #54 0x7a7eb2162292 in nsAppShell::Run() /widget/gtk/nsAppShell.cpp:470:33
        #55 0x7a7eb6f7314e in XRE_RunAppShell() /toolkit/xre/nsEmbedFunctions.cpp:712:20
        #56 0x7a7ea83649ca in RunInternal /ipc/chromium/src/base/message_loop.cc:370:10
        #57 0x7a7ea83649ca in RunHandler /ipc/chromium/src/base/message_loop.cc:363:3
        #58 0x7a7ea83649ca in MessageLoop::Run() /ipc/chromium/src/base/message_loop.cc:345:3
        #59 0x7a7eb6f726a3 in XRE_InitChildProcess(int, char**, XREChildData const*) /toolkit/xre/nsEmbedFunctions.cpp:647:34
        #60 0x5e1e182e178c in content_process_main /browser/app/../../ipc/contentproc/plugin-container.cpp:57:28
        #61 0x5e1e182e178c in main /browser/app/nsBrowserApp.cpp:378:18
        #62 0x7a7ecfb87d8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
    
    SUMMARY: AddressSanitizer: heap-use-after-free /dom/indexedDB/Key.cpp:720:20 in mozilla::Result<mozilla::Ok, nsresult> mozilla::dom::indexedDB::Key::EncodeAsString<unsigned char>(mozilla::Span<unsigned char const, 18446744073709551615ul>, unsigned char)
    Shadow bytes around the buggy address:
      0x529000388f80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x529000389000: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x529000389080: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x529000389100: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x529000389180: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
    =>0x529000389200:[fd]fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
      0x529000389280: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
      0x529000389300: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
      0x529000389380: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
      0x529000389400: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
      0x529000389480: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
    Shadow byte legend (one shadow byte represents 8 application bytes):
      Addressable:           00
      Partially addressable: 01 02 03 04 05 06 07 
      Heap left redzone:       fa
      Freed heap region:       fd
      Stack left redzone:      f1
      Stack mid redzone:       f2
      Stack right redzone:     f3
      Stack after return:      f5
      Stack use after scope:   f8
      Global redzone:          f9
      Global init order:       f6
      Poisoned by user:        f7
      Container overflow:      fc
      Array cookie:            ac
      Intra object redzone:    bb
      ASan internal:           fe
      Left alloca redzone:     ca
      Right alloca redzone:    cb
    ==518223==ABORTING

Comment 1

[Jason Kratzer [:jkratzer]]

Attachment: Testcase

Comment 2

[Jason Kratzer [:jkratzer]]

This bug appears to be timing dependent. I've managed to get a pernosco session for the non-reduced version of the testcase attached here. I'll link it here shortly once it's been processed.

Comment 3

[Jason Kratzer [:jkratzer]]

A pernosco session for this bug can be found here.

Comment 4

[Bugmon [:jkratzer for issues]]

Verified bug as reproducible on mozilla-central 20240509212246-8f49349eeb0e.
Unable to bisect testcase (Unable to launch the start build!):

Start: 55608cb73889b742af7c22a62da300048606e894 (20230512040642)
End: ee7969730d0cbf6ff5e83d27255443ac152ad42d (20240509094442)
BuildFlags: BuildFlags(asan=True, tsan=False, debug=False, fuzzing=True, coverage=False, valgrind=False, no_opt=False, fuzzilli=False, nyx=False)

Comment 5

[Jan Varga [:janv]]

This is probably related to bug 1878134.
GetByteSpanFromJSBufferSource may trigger GC which releases the object but we still try to use it in EncodeAsString.
It seems the object needs to be rooted before calling GetByteSpanFromJSBufferSource.

Comment 6

[Jari Jalkanen [:jari]]

Attachment: Bug 1895951 - Use a better alias for spec conformance. r=#dom-storage

Comment 7

[Jari Jalkanen [:jari]]

This is a speculative fix. As Jan said, from the logs it looks like the garbage collector plucks the array object while we are working with it.

However, I was unable to reproduce the issue with grizzly, or as a crashtest, even in the test-verify mode.

Attempts to run the garbage collector manually with TestUtils::Gc and with the JS::NonIncrementalGC method also didn't produce any findings, neither with the attached test case nor with the idb-binary-key*.htm web platform tests which cover this code.

Comment 8

[Jari Jalkanen [:jari]]

Comment on attachment 9401439 [details]
Bug 1895951 - Use a better alias for spec conformance. r=#dom-storage

Security Approval Request

• How easily could an exploit be constructed based on the patch?: After the garbage collector accidentally releases an array of chosen size, its contents are copied to valid memory and are available to read. With enough tries, an exploiter can read memory which does not belong to Firefox.
• 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 branches (beta, release, and/or ESR) are affected by this flaw, and do the release status flags reflect this affected/unaffected state correctly?: beta
• If not all supported branches, which bug introduced the flaw?: Bug 1878134
• Do you have backports for the affected branches?: No
• If not, how different, hard to create, and risky will they be?: It is a simple patch
• How likely is this patch to cause regressions; how much testing does it need?: It roots a JS object in various contexts, otherwise it is as before and passes all the checks as before.
• Is the patch ready to land after security approval is given?: Yes
• Is Android affected?: Yes

Comment 9

[Tom Ritter [:tjr]]

Comment on attachment 9401439 [details]
Bug 1895951 - Use a better alias for spec conformance. r=#dom-storage

approved to land and uplift

Comment 10

[Jari Jalkanen [:jari]]

Attachment: Bug 1895951 - Use a better alias for spec conformance. r=#dom-storage

Original Revision: https://phabricator.services.mozilla.com/D210185

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ca9ef1ccdd00
Use a better alias for spec conformance. r=dom-storage-reviewers,janv

Comment 12

[Tom Schuster (Out until June 1st)]

I think someone from the JavaScript GC team should be involved here. This patch doesn't make a lot of sense to me, especially the rooting in IsDetachedBuffer should just be a n-op.

Comment 13

[Jari Jalkanen [:jari]]

Attachment: Bug 1895951 - Use a better alias for spec conformance. r=#dom-storage

Original Revision: https://phabricator.services.mozilla.com/D210185

Comment 14

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/ca9ef1ccdd00

Comment 15

[Bugmon [:jkratzer for issues]]

Bug marked as FIXED but still reproduces on mozilla-central 20240515202418-b7871b7f2c05. If you believe this to be incorrect, please remove the bugmon keyword to prevent further analysis.

Comment 16

[Jan Varga [:janv]]

(In reply to Tom Schuster (MoCo) from comment #12)

I think someone from the JavaScript GC team should be involved here. This patch doesn't make a lot of sense to me, especially the rooting in IsDetachedBuffer should just be a n-op.

Sorry, I should have insisted on some kind of manual testing.
It seems some kind of rooting needs to be added to Key::EncodeJSValInternal as well.

Comment 17

[Jens Stutte [:jstutte]]

(In reply to Jan Varga [:janv] from comment #16)

Sorry, I should have insisted on some kind of manual testing.

Luckily bugmon is here to check :-) even though according to comment 7 we were not able to reproduce.

Comment 18

[Jan Varga [:janv]]

(In reply to Jan Varga [:janv] from comment #16)

It seems some kind of rooting needs to be added to Key::EncodeJSValInternal as well.

Actually, the objects are already rooted at https://searchfox.org/mozilla-central/source/__GENERATED__/dom/bindings/IDBFactoryBinding.cpp#414-419

So this probably needs more investigation/debugging.

Comment 19

[Jari Jalkanen [:jari]]

In summary, the worker script does

self.onmessage = async function (e) {
  o[0] = new Float64Array(2032)
  await scheduler.postTask(async function () {
    try { indexedDB.cmp(undefined, o[0]) } catch (e) {}
  }, {
    'priority': 'user-blocking',
  })
}

and in the log, o[0] seems to have been garbage collected.

Comment 20

[Jari Jalkanen [:jari]]

So the issue could be that o[0] is an implicit global variable and when postMessage is called for the second time for the same worker, the variable o[0] gets reassigned, leading to a problem for indexedDB which is still processing the previous task.

Comment 21

[Jari Jalkanen [:jari]]

Could we perhaps back out the patch as it is not needed and the bug still remains @RyanVM ?

Comment 22

[Ryan VanderMeulen [:RyanVM]]

Sure, backed out.
https://hg.mozilla.org/integration/autoland/rev/d0d5850197a21c9a7545101a093126cb473c28a1

Comment 23

[Jari Jalkanen [:jari]]

--Since this might not be specific to this API or IndexedDB, do we by any chance see any crashes with a similar pattern elsewhere?-- edit: obsolete

Comment 24

[Jari Jalkanen [:jari]]

The Pernosco session revealed that the new call to JS_GetArrayBufferViewBuffer, added by the regressing bug, to check if the buffer is detached, leads to the buffer getting detached. A fix is incoming.

Comment 25

[Jon Coppeard (:jonco)]

From looking at the ASAN report the problem seems to be that the code gets a pointer into a TypedArray's backing data and then causes that data to be moved elsewhere and the pointer to become stale.

This happens because IsDetached calls JS_GetArrayBufferViewBuffer. This gets the array buffer backing an object - or creates one if it does not exist. In this case the typed array passed in didn't have an array buffer backing it so one is created and its data copied across. The original allocation is freed.

I believe the best way to check for detached buffers is calling isDetached on the result of ArrayBufferView::fromObject(). sfink knows more about this than I do though.

You may not need to do this. JS_GetObjectAsArrayBufferView and JS::GetObjectAsArrayBuffer will return null pointer / zero byte length for detached buffers.

Finally, I want to point out that GetByteSpanFromJSBufferSource says it returns a copy of the bytes held by the buffer, but that is not true. It returns a pointer into the buffer, which will become stale if the object dies or something else happens to the buffer.

Comment 26

[Steve Fink [:sfink] [:s:]]

sfink has opinions!

GetByteSpanFromJSBufferSource is a bad API and should either be modified to take an AutoRequireNoGC&, or removed entirely. It hands back unstable, easily invalidatable pointer + length values. Right now, it's a "call this to hide from the hazard analysis" footgun.

I should update the hazard analysis to treat the length returned by JS_GetObjectAsArrayBufferView as "fragile" — as in, it needs to be used and forgotten right away, and if you call anything that might invalidate it before you stop using it, it should cause the analysis to fail. I'm not sure it would catch anything here, though. Actually, JS_GetObjectAsArrayBufferView should probably be removed or somehow restricted to dom/bindings/TypedArray.h... which doesn't use it currently, so maybe removal is good. The only other use in the tree is safe, but easily replaced as well.

EncodeJSValInternal should use mozilla::dom::(TypedArray_base)::ProcessData(). Hopefully EncodeAsString can take what it provides, but perhaps some small amount of adaptation will be needed. That'll probably require explicitly handling detached buffers, preferably first.

This happens because IsDetached calls JS_GetArrayBufferViewBuffer. This gets the array buffer backing an object - or creates one if it does not exist.

(It's IsDetachedBuffer.) This seems unfortunate. Switching to the TypedArray.h APIs should fix this, I think.

Apologies for providing such dangerous APIs in the first place. They're very hard to use without violating subtle and invisible invariants. ProcessData and ProcessFixedData are vastly safer, though they still have issues with error handling.

Comment 27

[Steve Fink [:sfink] [:s:]]

Attachment: Bug 1895951 - Switch IndexedDB to newer ArrayBuffer (or view) APIs. r=#dom-storage

Comment 28

[Steve Fink [:sfink] [:s:]]

Hm, I didn't necessarily intend to take this bug by posting a patch, but this is doing a lot of JSAPI access so maybe it makes sense. I wasn't sure the newer APIs were going to be easy to figure out, so I mocked something up and I think it works. I migrated some of the comments, but I dropped several and different orderings are mixed together. Does anyone want to take the patch and fix that up? I didn't dig to try to figure out what spec things were referring to.

Comment 29

[Jari Jalkanen [:jari]]

Comment on attachment 9403116 [details]
Bug 1895951 - Switch IndexedDB to newer ArrayBuffer (or view) APIs. r=#dom-storage

Security Approval Request

• How easily could an exploit be constructed based on the patch?: After the garbage collector accidentally releases an array of chosen size, its contents are copied to valid memory and are available to read. With enough tries, an exploiter can read memory which does not belong to Firefox.
• 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 branches (beta, release, and/or ESR) are affected by this flaw, and do the release status flags reflect this affected/unaffected state correctly?: firefox127, firefox128, beta
• If not all supported branches, which bug introduced the flaw?: Bug 1878134
• Do you have backports for the affected branches?: No
• If not, how different, hard to create, and risky will they be?: It is a simple patch
• How likely is this patch to cause regressions; how much testing does it need?: It switches the previous risky JS API's with new and safe ones, otherwise it changes nothing for the users and passes the same checks as before.
• Is the patch ready to land after security approval is given?: Yes
• Is Android affected?: Yes

Comment 30

[Tom Ritter [:tjr]]

Comment on attachment 9403116 [details]
Bug 1895951 - Switch IndexedDB to newer ArrayBuffer (or view) APIs. r=#dom-storage

Clearing flag until patch is ready

Comment 31

[Daniel Holbert [:dholbert]]

[ran across this bug in regression bug triage]

(In reply to Steve Fink [:sfink] [:s:] from comment #28)

Hm, I didn't necessarily intend to take this bug by posting a patch [...]
Does anyone want to take the patch and fix that up?

Looks like :janv picked this up, based on recent phabricator activity. --> Updating assignee.

Comment 32

[Jan Varga [:janv]]

Attachment: Bug 1895951 - Schedule sending of results after releasing current runnable; r=#dom-storage

Comment 33

[Phabricator Automation]

Comment on attachment 9405460 [details]
Bug 1895951 - Schedule sending of results after releasing current runnable; r=#dom-storage

Revision D212525 was moved to bug 1892875. Setting attachment 9405460 [details] to obsolete.

Comment 34

[Jan Varga [:janv]]

Comment on attachment 9403116 [details]
Bug 1895951 - Switch IndexedDB to newer ArrayBuffer (or view) APIs. r=#dom-storage

Security Approval Request

• How easily could an exploit be constructed based on the patch?: The code gets a pointer into a TypedArray's backing data and then causes that data to be moved elsewhere and the pointer to become stale.
  If the original (stale) pointer is accessed to read or write data, then this could cause the product to read or modify data that is in use by a different function or process. Depending on how the newly-allocated memory is used, this could lead to a denial of service, information exposure, or code execution.
• 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 branches (beta, release, and/or ESR) are affected by this flaw, and do the release status flags reflect this affected/unaffected state correctly?: firefox127 (release), firefox128 (beta), firefox129 (nightly)
• If not all supported branches, which bug introduced the flaw?: Bug 1878134
• Do you have backports for the affected branches?: No
• If not, how different, hard to create, and risky will they be?: It should be easy. The patch is not large.
• How likely is this patch to cause regressions; how much testing does it need?: The patch replaces the previous risky JS API calls with new and safe ones, otherwise it changes nothing for the users and passes the same checks as before.
  The patch was heavily tested locally.
• Is the patch ready to land after security approval is given?: Yes
• Is Android affected?: Yes

Comment 35

[Daniel Veditz [:dveditz]]

Comment on attachment 9403116 [details]
Bug 1895951 - Switch IndexedDB to newer ArrayBuffer (or view) APIs. r=#dom-storage

sec-approval+ = dveditz. Please also prepare a beta uplift patch.

Comment 36

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/2f6aee8f086d
Switch IndexedDB to newer ArrayBuffer (or view) APIs. r=dom-storage-reviewers,sfink,jari

Comment 37

[Pulsebot]

Backout by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/77eda1ea90c2
Backed out changeset 2f6aee8f086d for causing assertion failure at TypedArray.h. CLOSED TREE

Comment 38

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Backed out for causing assertion failure in TypedArray.h:
https://hg.mozilla.org/integration/autoland/rev/77eda1ea90c22a621ea95fc6abcd756278ca6e8d

Push with failure
Failure log

[task 2024-06-18T10:41:28.800Z] 10:41:28     INFO - REFTEST TEST-START | dom/indexedDB/crashtests/1813284-1.html
[task 2024-06-18T10:41:28.802Z] 10:41:28     INFO - REFTEST TEST-LOAD | file:///D:/task_171870468607253/build/tests/reftest/tests/dom/indexedDB/crashtests/1813284-1.html | 613 / 4037 (15%)
[task 2024-06-18T10:41:30.253Z] 10:41:30     INFO - [8092] Assertion failure: span.Length() <= 2147483647i32 (Bindings must have checked ArrayBuffer{View} length), at /builds/worker/workspace/obj-build/dist/include/mozilla/dom/TypedArray.h:700
[task 2024-06-18T10:41:30.337Z] 10:41:30     INFO - #01: mozilla::dom::TypedArray_base<JS::ArrayBufferView>::GetCurrentData() const [dom/bindings/TypedArray.h:699]
[task 2024-06-18T10:41:30.339Z] 10:41:30     INFO - #02: mozilla::dom::TypedArray_base<JS::ArrayBufferView>::ProcessDataHelper<const std::function<mozilla::Result<mozilla::Ok,nsresult> (const mozilla::Span<unsigned char,18446744073709551615> &, JS::AutoCheckCannotGC &&)> &>(std::function<mozilla::Result<mozilla::Ok,nsresult> (const mozilla::Span<unsigned char,18446744073709551615> &, JS::AutoCheckCannotGC &&)> const&) const [dom/bindings/TypedArray.h:628]
[task 2024-06-18T10:41:30.340Z] 10:41:30     INFO - #03: mozilla::dom::indexedDB::Key::EncodeBinary(JS::ArrayBufferOrView const&, unsigned char) [dom/indexedDB/Key.cpp:907]
[task 2024-06-18T10:41:30.340Z] 10:41:30     INFO - #04: mozilla::dom::indexedDB::Key::EncodeJSValInternal(JSContext*, JS::Handle<JS::Value>, unsigned char, unsigned short) [dom/indexedDB/Key.cpp:441]
[task 2024-06-18T10:41:30.341Z] 10:41:30     INFO - #05: mozilla::dom::indexedDB::Key::SetFromJSVal(JSContext*, JS::Handle<JS::Value>) [dom/indexedDB/Key.cpp:990]
[task 2024-06-18T10:41:30.341Z] 10:41:30     INFO - #06: mozilla::dom::IDBFactory::Cmp(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, mozilla::ErrorResult&) [dom/indexedDB/IDBFactory.cpp:531]
[task 2024-06-18T10:41:30.342Z] 10:41:30     INFO - #07: mozilla::dom::IDBFactory_Binding::cmp(JSContext*, JS::Handle<JSObject *>, void*, JSJitMethodCallArgs const&) [s3:gecko-generated-sources:635b09f823ecf5c179b56a4e6d0bd5909edfc8f4ed7b288b0be6e57ffb730c099bdeef142b3c1dbd05808ee15d373f3dd8839d67abb4e3096075852a786cb966/dom/bindings/IDBFactoryBinding.cpp::399]
[task 2024-06-18T10:41:30.343Z] 10:41:30     INFO - #08: mozilla::dom::binding_detail::GenericMethod<mozilla::dom::binding_detail::NormalThisPolicy,mozilla::dom::binding_detail::ThrowExceptions>(JSContext*, unsigned int, JS::Value*) [dom/bindings/BindingUtils.cpp:3270]
[task 2024-06-18T10:41:30.344Z] 10:41:30     INFO - #09: CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), js::CallReason, JS::CallArgs const&) [js/src/vm/Interpreter.cpp:487]
[task 2024-06-18T10:41:30.345Z] 10:41:30     INFO - #10: js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) [js/src/vm/Interpreter.cpp:581]
[task 2024-06-18T10:41:30.345Z] 10:41:30     INFO - #11: js::Interpret(JSContext*, js::RunState&) [js/src/vm/Interpreter.cpp:3291]
[task 2024-06-18T10:41:30.346Z] 10:41:30     INFO - #12: js::RunScript(JSContext*, js::RunState&) [js/src/vm/Interpreter.cpp:459]
[task 2024-06-18T10:41:30.347Z] 10:41:30     INFO - #13: js::ExecuteKernel(JSContext*, JS::Handle<JSScript *>, JS::Handle<JSObject *>, js::AbstractFramePtr, JS::MutableHandle<JS::Value>) [js/src/vm/Interpreter.cpp:846]
[task 2024-06-18T10:41:30.347Z] 10:41:30     INFO - #14: js::Execute(JSContext*, JS::Handle<JSScript *>, JS::Handle<JSObject *>, JS::MutableHandle<JS::Value>) [js/src/vm/Interpreter.cpp:878]
[task 2024-06-18T10:41:30.348Z] 10:41:30     INFO - #15: ExecuteScript(JSContext*, JS::Handle<JSObject *>, JS::Handle<JSScript *>, JS::MutableHandle<JS::Value>) [js/src/vm/CompilationAndEvaluation.cpp:494]
[task 2024-06-18T10:41:30.348Z] 10:41:30     INFO - #16: JS_ExecuteScript(JSContext*, JS::Handle<JSScript *>) [js/src/vm/CompilationAndEvaluation.cpp:518]
[task 2024-06-18T10:41:30.349Z] 10:41:30     INFO - #17: mozilla::dom::JSExecutionContext::ExecScript() [dom/base/JSExecutionContext.cpp:234]
[task 2024-06-18T10:41:30.350Z] 10:41:30     INFO - #18: mozilla::dom::ScriptLoader::EvaluateScript(nsIGlobalObject*, JS::loader::ScriptLoadRequest*) [dom/script/ScriptLoader.cpp:2766]
[task 2024-06-18T10:41:30.350Z] 10:41:30     INFO - #19: mozilla::dom::ScriptLoader::EvaluateScriptElement(JS::loader::ScriptLoadRequest*) [dom/script/ScriptLoader.cpp:2549]
[task 2024-06-18T10:41:30.351Z] 10:41:30     INFO - #20: mozilla::dom::ScriptLoader::ProcessRequest(JS::loader::ScriptLoadRequest*) [dom/script/ScriptLoader.cpp:2188]
[task 2024-06-18T10:41:30.352Z] 10:41:30     INFO - #21: mozilla::dom::ScriptLoader::ProcessInlineScript(nsIScriptElement*, JS::loader::ScriptKind) [dom/script/ScriptLoader.cpp:1443]
[task 2024-06-18T10:41:30.352Z] 10:41:30     INFO - #22: mozilla::dom::ScriptLoader::ProcessScriptElement(nsIScriptElement*) [dom/script/ScriptLoader.cpp:1036]
[task 2024-06-18T10:41:30.353Z] 10:41:30     INFO - #23: mozilla::dom::ScriptElement::MaybeProcessScript() [dom/script/ScriptElement.cpp:210]
[task 2024-06-18T10:41:30.353Z] 10:41:30     INFO - #24: nsHtml5TreeOpExecutor::RunScript(nsIContent*, bool) [parser/html/nsHtml5TreeOpExecutor.cpp:957]
[task 2024-06-18T10:41:30.354Z] 10:41:30     INFO - #25: nsHtml5TreeOpExecutor::RunFlushLoop() [parser/html/nsHtml5TreeOpExecutor.cpp:745]
[task 2024-06-18T10:41:30.354Z] 10:41:30     INFO - #26: nsHtml5ExecutorFlusher::Run() [parser/html/nsHtml5StreamParser.cpp:164]
[task 2024-06-18T10:41:30.355Z] 10:41:30     INFO - #27: mozilla::RunnableTask::Run() [xpcom/threads/TaskController.cpp:581]
[task 2024-06-18T10:41:30.355Z] 10:41:30     INFO - #28: mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex &> const&) [xpcom/threads/TaskController.cpp:907]
[task 2024-06-18T10:41:30.356Z] 10:41:30     INFO - #29: mozilla::TaskController::ExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex &> const&) [xpcom/threads/TaskController.cpp:730]
[task 2024-06-18T10:41:30.356Z] 10:41:30     INFO - #30: mozilla::TaskController::ProcessPendingMTTask(bool) [xpcom/threads/TaskController.cpp:516]
[task 2024-06-18T10:41:30.357Z] 10:41:30     INFO - #31: mozilla::detail::RunnableFunction<`lambda at /builds/worker/checkouts/gecko/xpcom/threads/TaskController.cpp:234:7'>::Run() [xpcom/threads/nsThreadUtils.h:549]
[task 2024-06-18T10:41:30.357Z] 10:41:30     INFO - #32: nsThread::ProcessNextEvent(bool, bool*) [xpcom/threads/nsThread.cpp:1208]
[task 2024-06-18T10:41:30.358Z] 10:41:30     INFO - #33: NS_ProcessNextEvent(nsIThread*, bool) [xpcom/threads/nsThreadUtils.cpp:480]
[task 2024-06-18T10:41:30.359Z] 10:41:30     INFO - #34: mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) [ipc/glue/MessagePump.cpp:85]
[task 2024-06-18T10:41:30.359Z] 10:41:30     INFO - #35: MessageLoop::RunHandler() [ipc/chromium/src/base/message_loop.cc:364]
[task 2024-06-18T10:41:30.360Z] 10:41:30     INFO - #36: MessageLoop::Run() [ipc/chromium/src/base/message_loop.cc:346]
[task 2024-06-18T10:41:30.360Z] 10:41:30     INFO - #37: nsBaseAppShell::Run() [widget/nsBaseAppShell.cpp:150]
[task 2024-06-18T10:41:30.360Z] 10:41:30     INFO - #38: nsAppShell::Run() [widget/windows/nsAppShell.cpp:655]
[task 2024-06-18T10:41:30.361Z] 10:41:30     INFO - #39: XRE_RunAppShell() [toolkit/xre/nsEmbedFunctions.cpp:712]
[task 2024-06-18T10:41:30.361Z] 10:41:30     INFO - #40: mozilla::ipc::MessagePumpForChildProcess::Run(base::MessagePump::Delegate*) [ipc/glue/MessagePump.cpp:235]
[task 2024-06-18T10:41:30.361Z] 10:41:30     INFO - #41: MessageLoop::RunHandler() [ipc/chromium/src/base/message_loop.cc:364]
[task 2024-06-18T10:41:30.362Z] 10:41:30     INFO - #42: MessageLoop::Run() [ipc/chromium/src/base/message_loop.cc:346]
[task 2024-06-18T10:41:30.362Z] 10:41:30     INFO - #43: XRE_InitChildProcess(int, char**, XREChildData const*) [toolkit/xre/nsEmbedFunctions.cpp:651]
[task 2024-06-18T10:41:30.363Z] 10:41:30     INFO - #44: NS_internal_main(int, char**, char**) [browser/app/nsBrowserApp.cpp:378]
[task 2024-06-18T10:41:30.363Z] 10:41:30     INFO - #45: wmain(int, wchar_t**) [toolkit/xre/nsWindowsWMain.cpp:151]
[task 2024-06-18T10:41:30.364Z] 10:41:30     INFO - #46: __scrt_common_main_seh() [/builds/worker/workspace/obj-build/browser/app/D:/a/_work/1/s/src/vctools/crt/vcstartup/src/startup/exe_common.inl:288]
[task 2024-06-18T10:41:30.364Z] 10:41:30     INFO - #47: BaseThreadInitThunk [C:\Windows\System32\KERNEL32.DLL + 0x1257d]
[task 2024-06-18T10:41:30.364Z] 10:41:30     INFO - #48: RtlUserThreadStart [C:\Windows\SYSTEM32\ntdll.dll + 0x5aa48]

Comment 39

[Jan Varga [:janv]]

So the crash test looks like this:

<script>
  // This test allocates >= 4GB of memory even if it succeeds.
  let a = new ArrayBuffer(4294967296)
  let b = new Uint32Array(a)
  self.indexedDB.cmp(b, undefined)
</script>

and the assertion is:

Assertion failure: span.Length() <= 2147483647i32 (Bindings must have checked ArrayBuffer{View} length)

It seems we just need to check the length to be less than 2147483647i32.

Comment 40

[Jan Varga [:janv]]

(In reply to Jan Varga [:janv] from comment #39)

So the crash test looks like this:

<script>
  // This test allocates >= 4GB of memory even if it succeeds.
  let a = new ArrayBuffer(4294967296)
  let b = new Uint32Array(a)
  self.indexedDB.cmp(b, undefined)
</script>

and the assertion is:

Assertion failure: span.Length() <= 2147483647i32 (Bindings must have checked ArrayBuffer{View} length)

It seems we just need to check the length to be less than 2147483647i32.

Well, that's actually not so easy with the current APIs because I'm not sure if it's 100% safe to check the length prior the ProcessData call.
Steve, I wonder if the assertion https://searchfox.org/mozilla-central/rev/b11735b86bb4d416c918e2b2413456561beff50c/dom/bindings/TypedArray.h#700 is still needed given uint32_t mLength member has been removed.
The member still existed in this revision https://hg.mozilla.org/mozilla-central/file/b9bbd30d9797f1e54b781a0cce2d8e39339ae418/dom/bindings/TypedArray.h
It was then removed by this changeset https://hg.mozilla.org/mozilla-central/rev/37c6a7ae5981222051c86bde449389e8f69f49c5
The assertion happens before ProcessData calls the callback, so checks like this https://searchfox.org/mozilla-central/rev/b11735b86bb4d416c918e2b2413456561beff50c/dom/simpledb/SDBConnection.cpp#53
don't make much sense.

Comment 41

[Steve Fink [:sfink] [:s:]]

Hrm, that's kind of gross.

ArrayBuffers used to be limited to 32 bits both inside SM and outside (various parameters were int32_t). That eventually became too restrictive on 64-bit for Wasm, so we switched internally to use size_t but kept many of the external interfaces as int32_t in case it was being depended upon.

Now it seems like we have a mismatch, where part of the code is expecting the DOM bindings layer to have rejected longer arrays. Which used to happen reliably but is now missing.

It seems like either we could add the check back in, or remove the assert and do a quick audit that there won't be any buffer overruns or denial of service problems when larger-than-uint32_t lengths make it into the DOM.

Comment 42

[Steve Fink [:sfink] [:s:]]

Note that if anything in the DOM permits GrowableArrayBuffers and we wanted to restrict to ~2^32, then we'd need to do the DOM bindings check on the max allowed size, not the current size.

Comment 43

[Jan Varga [:janv]]

(In reply to Steve Fink [:sfink] [:s:] from comment #41)

It seems like either we could add the check back in, or remove the assert and do a quick audit that there won't be any buffer overruns or denial of service problems when larger-than-uint32_t lengths make it into the DOM.

Thanks for the info. Both options seem a bit risky, and we need to resolve this security bug quickly. How about we take an intermediate step instead? I'll submit a WIP patch for that."

Comment 44

[Jan Varga [:janv]]

Attachment: Bug 1895951 - Add TypedArray::MaybeProcessData; r=sfink

There's currently no easy safe way to check the length prior calling
TypedArray::ProcessData. If the length is not checked and the length is greater
than INT32_MAX, a release assert is hit. TypedArray::MaybeProcessData provides
a way to check the condition in the callback and return an error.

Comment 45

[Ryan VanderMeulen [:RyanVM]]

FYI, Fx128 is already in RC now and past the point of being available for an uplift this cycle, so please double-check with the sec team on timing before attempting to land again.

Comment 46

[Peter Van der Beken [:peterv]]

(In reply to Steve Fink [:sfink] [:s:] from comment #41)

Now it seems like we have a mismatch, where part of the code is expecting the DOM bindings layer to have rejected longer arrays.

The binding layer still checks (see https://searchfox.org/mozilla-central/rev/3d173a6ad865eb778eb7a85de900e92774559ed6/dom/bindings/Codegen.py#6783-6795), but TypedArray::Init itself doesn't, and that's the API that https://phabricator.services.mozilla.com/D211140 uses.

Which used to happen reliably but is now missing.

TypedArray::Create is mostly used to return typedarrays to JS, so it's not really involved here.

Comment 47

[Phabricator Automation]

Comment on attachment 9410776 [details]
Bug 1895951 - Add TypedArray::MaybeProcessData; r=sfink

Revision D215478 was moved to bug 1906083. Setting attachment 9410776 [details] to obsolete.

Comment 48

[Frederik Braun [:freddy]]

(In reply to Steve Fink [:sfink] [:s:] from comment #41)

Hrm, that's kind of gross.

ArrayBuffers used to be limited to 32 bits both inside SM and outside (various parameters were int32_t). That eventually became too restrictive on 64-bit for Wasm, so we switched internally to use size_t but kept many of the external interfaces as int32_t in case it was being depended upon.

That sounds a bit...dangerous. Is there a follow-up bug for this pattern, Steve?

Comment 49

[Jan Varga [:janv]]

Ok, I tried some things, but it seems I can't unset the sec-approcal+

Comment 50

[Jan Varga [:janv]]

Can we get a new sec-approval for landing on latest mozilla-central ?
Thanks.

Comment 51

[Steve Fink [:sfink] [:s:]]

(In reply to Frederik Braun [:freddy] from comment #48)

(In reply to Steve Fink [:sfink] [:s:] from comment #41)

Hrm, that's kind of gross.

ArrayBuffers used to be limited to 32 bits both inside SM and outside (various parameters were int32_t). That eventually became too restrictive on 64-bit for Wasm, so we switched internally to use size_t but kept many of the external interfaces as int32_t in case it was being depended upon.

That sounds a bit...dangerous. Is there a follow-up bug for this pattern, Steve?

Filed bug 1907421.

Comment 52

[Daniel Veditz [:dveditz]]

Comment on attachment 9403116 [details]
Bug 1895951 - Switch IndexedDB to newer ArrayBuffer (or view) APIs. r=#dom-storage

sec-approval+ = dveditz

Comment 53

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/582ec297dd79
Switch IndexedDB to newer ArrayBuffer (or view) APIs. r=dom-storage-reviewers,sfink,jari

Comment 54

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Backed out for hazard failures:
https://hg.mozilla.org/integration/autoland/rev/a9dc303a4f3590fb85049c83a9213adabfd539f5

Push with failure
Failure log

[task 2024-07-12T16:47:50.897Z] TEST-UNEXPECTED-FAIL | hazards | unrooted 'aNoGC' of type 'JS::AutoCheckCannotGC&&' live across GC call at dom/indexedDB/Key.cpp:931
[task 2024-07-12T16:47:50.897Z] TEST-UNEXPECTED-FAIL | hazards | unrooted '__args#1' of type 'JS::AutoCheckCannotGC&&' live across GC call at /builds/worker/fetches/sysroot-x86_64-linux-gnu/usr/include/c++/8/bits/std_function.h:283
[task 2024-07-12T16:47:50.897Z] TEST-UNEXPECTED-FAIL | hazards | unrooted '__args#1' of type 'JS::AutoCheckCannotGC&&' live across GC call at /builds/worker/fetches/sysroot-x86_64-linux-gnu/usr/include/c++/8/bits/std_function.h:687
[task 2024-07-12T16:47:50.897Z] TEST-UNEXPECTED-FAIL | hazards | 3 rooting hazards detected

Comment 55

[Jan Varga [:janv]]

sfink and I discussed the hazards a bit last week. He already has some fixes, but more work still needs to be done.

Comment 56

[Donal Meehan [:dmeehan]]

:janv, next week is the final week of beta for Fx129.
For Comment 55, do you expect to have a fix by next week in time to uplift?

Comment 57

[Jan Varga [:janv]]

(In reply to Donal Meehan [:dmeehan] from comment #56)

:janv, next week is the final week of beta for Fx129.
For Comment 55, do you expect to have a fix by next week in time to uplift?

sfink already provided a fix, I'm doing some final testing, I'll be landing it soon.

Comment 58

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/148aeb0a04bb
Switch IndexedDB to newer ArrayBuffer (or view) APIs. r=dom-storage-reviewers,sfink,jari

Comment 59

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/148aeb0a04bb

Comment 60

[Bugmon [:jkratzer for issues]]

Verified bug as fixed on rev mozilla-central 20240719162139-0614dadb2b13.
Removing bugmon keyword as no further action possible. Please review the bug and re-add the keyword for further analysis.

Comment 61

[BugBot [:suhaib / :marco/ :calixte]]

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

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

For more information, please visit BugBot documentation.

Comment 62

[Donal Meehan [:dmeehan]]

To add to Comment 61, please also add an ESR128 uplift request.
It grafts cleanly to ESR128.

Comment 63

[Jan Varga [:janv]]

Comment on attachment 9403116 [details]
Bug 1895951 - Switch IndexedDB to newer ArrayBuffer (or view) APIs. r=#dom-storage

Beta/Release Uplift Approval Request

• User impact if declined: Users could still encounter use-after-free issues including other mysterious bugs like 1905111.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None (bug 1906083 landed during 129 cycle)
• Risk to taking this patch: Medium
• Why is the change risky/not risky? (and alternatives if risky): The changes are not totally trivial but they have been heavily tested and reviewed by multiple developers.
• String changes made/needed: None
• Is Android affected?: Yes

Comment 64

[Jan Varga [:janv]]

Comment on attachment 9403116 [details]
Bug 1895951 - Switch IndexedDB to newer ArrayBuffer (or view) APIs. r=#dom-storage

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration:
• User impact if declined: Users could still encounter use-after-free issues including other mysterious bugs like 1905111.
• Fix Landed on Version: 130
• Risk to taking this patch: Medium
• Why is the change risky/not risky? (and alternatives if risky): The changes are not totally trivial but they have been heavily tested and reviewed by multiple developers.

Comment 65

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/1ade9d2a8292

Comment 66

[Donal Meehan [:dmeehan]]

Comment on attachment 9403116 [details]
Bug 1895951 - Switch IndexedDB to newer ArrayBuffer (or view) APIs. r=#dom-storage

Approved for 128.0b9

Comment 67

[Donal Meehan [:dmeehan]]

Comment on attachment 9403116 [details]
Bug 1895951 - Switch IndexedDB to newer ArrayBuffer (or view) APIs. r=#dom-storage

Approved for 128.1esr.

Comment 68

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr128/rev/2c95a4fcedf8

Comment 69

[Jan Varga [:janv]]

It seems, this was causing bug 1905111.

Comment 70

[Tyson Smith [:tsmith]]

Attachment: advisory.txt

Comment 71

[Tyson Smith [:tsmith]]

Attachment: advisory.txt