Closed Bug 1164141 (CVE-2026-2779) Opened 11 years ago Closed 5 months ago

crash in nsZipArchive::GetDataOffset(nsZipItem*)

Categories

(Core :: Networking: JAR, defect, P2)

Product:
Core
Component:
Networking: JAR
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
149 Branch
Tracking Flags:
Tracking Status
firefox41 --- wontfix
firefox46 --- wontfix
firefox47 --- wontfix
firefox48 --- wontfix
firefox49 --- wontfix
thunderbird_esr38 --- wontfix
firefox-esr102 --- wontfix
firefox-esr115 --- wontfix
firefox-esr128 --- wontfix
firefox-esr140 148+ fixed
firefox75 --- wontfix
firefox76 --- wontfix
firefox106 --- wontfix
firefox107 --- wontfix
firefox108 --- wontfix
firefox131 --- wontfix
firefox147 --- wontfix
firefox148 + fixed
firefox149 + fixed

People

(Reporter: alex_mayorga, Assigned: valentin)

References

Details

(4 keywords, Whiteboard: ShutDownKill, [necko-triaged][necko-priority-queue][adv-main148+] [adv-esr140.8+])

Crash Data

Attachments

(4 files, 1 obsolete file)

(secure)
48 bytes, text/x-phabricator-request
dveditz
: sec-approval+
Details | Review
(secure)
48 bytes, text/x-phabricator-request
Details | Review
(secure)
48 bytes, text/x-phabricator-request
phab-bot
: approval-mozilla-beta+
Details | Review
(secure)
48 bytes, text/x-phabricator-request
phab-bot
: approval-mozilla-esr140+
Details | Review
This bug was filed from the Socorro interface and is report bp-1e0c3658-5237-4dcd-a710-5c4da2150512. ============================================================= Crashing Thread Frame Module Signature Source 0 xul.dll nsZipArchive::GetDataOffset(nsZipItem*) modules/libjar/nsZipArchive.cpp 1 xul.dll nsZipArchive::GetData(nsZipItem*) modules/libjar/nsZipArchive.cpp 2 xul.dll nsJARInputStream::InitFile(nsJAR*, nsZipItem*) modules/libjar/nsJARInputStream.cpp 3 xul.dll nsJAR::GetInputStreamWithSpec(nsACString_internal const&, nsACString_internal const&, nsIInputStream**) modules/libjar/nsJAR.cpp 4 xul.dll nsJARInputThunk::Init() modules/libjar/nsJARChannel.cpp 5 xul.dll nsJARChannel::CreateJarInput(nsIZipReaderCache*, nsJARInputThunk**) modules/libjar/nsJARChannel.cpp 6 xul.dll nsJARChannel::Open(nsIInputStream**) modules/libjar/nsJARChannel.cpp 7 xul.dll mozJSComponentLoader::ObjectForLocation(ComponentLoaderInfo&, nsIFile*, JS::MutableHandle<JSObject*>, JS::MutableHandle<JSScript*>, char**, bool, JS::MutableHandle<JS::Value>) js/xpconnect/loader/mozJSComponentLoader.cpp 8 xul.dll mozJSComponentLoader::ImportInto(nsACString_internal const&, JS::Handle<JSObject*>, JSContext*, JS::MutableHandle<JSObject*>) js/xpconnect/loader/mozJSComponentLoader.cpp 9 xul.dll mozJSComponentLoader::Import(nsACString_internal const&, JS::Handle<JS::Value>, JSContext*, unsigned char, JS::MutableHandle<JS::Value>) js/xpconnect/loader/mozJSComponentLoader.cpp 10 xul.dll nsXPCComponents_Utils::Import(nsACString_internal const&, JS::Handle<JS::Value>, JSContext*, unsigned char, JS::MutableHandle<JS::Value>) js/xpconnect/src/XPCComponents.cpp 11 xul.dll XPTC__InvokebyIndex xpcom/reflect/xptcall/md/win32/xptcinvoke_asm_x86_64.asm 12 @0x2e4acf 13 xul.dll XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) js/xpconnect/src/XPCWrappedNative.cpp 14 xul.dll XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*) js/xpconnect/src/XPCWrappedNativeJSOps.cpp 15 xul.dll js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) js/src/vm/Interpreter.cpp 16 xul.dll Interpret js/src/vm/Interpreter.cpp 17 xul.dll js::RunScript(JSContext*, js::RunState&) js/src/vm/Interpreter.cpp 18 xul.dll js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) js/src/vm/Interpreter.cpp 19 xul.dll js::fun_call(JSContext*, unsigned int, JS::Value*) js/src/jsfun.cpp 20 xul.dll js::fun_apply(JSContext*, unsigned int, JS::Value*) js/src/jsfun.cpp 21 xul.dll js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) js/src/vm/Interpreter.cpp 22 xul.dll Interpret js/src/vm/Interpreter.cpp 23 xul.dll js::RunScript(JSContext*, js::RunState&) js/src/vm/Interpreter.cpp 24 xul.dll js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) js/src/vm/Interpreter.cpp 25 xul.dll js::CrossCompartmentWrapper::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) js/src/proxy/CrossCompartmentWrapper.cpp 26 xul.dll js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) js/src/vm/Interpreter.cpp 27 xul.dll js::Invoke(JSContext*, JS::Value const&, JS::Value const&, unsigned int, JS::Value const*, JS::MutableHandle<JS::Value>) js/src/vm/Interpreter.cpp 28 xul.dll js::NativeGetExistingProperty(JSContext*, JS::Handle<JSObject*>, JS::Handle<js::NativeObject*>, JS::Handle<js::Shape*>, JS::MutableHandle<JS::Value>) js/src/vm/NativeObject.cpp 29 xul.dll GetNameOperation js/src/vm/Interpreter.cpp 30 xul.dll Interpret js/src/vm/Interpreter.cpp 31 xul.dll js::RunScript(JSContext*, js::RunState&) js/src/vm/Interpreter.cpp 32 xul.dll js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) js/src/vm/Interpreter.cpp 33 xul.dll JS_CallFunctionValue(JSContext*, JS::Handle<JSObject*>, JS::Handle<JS::Value>, JS::HandleValueArray const&, JS::MutableHandle<JS::Value>) js/src/jsapi.cpp 34 xul.dll nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJS*, unsigned short, XPTMethodDescriptor const*, nsXPTCMiniVariant*) js/xpconnect/src/XPCWrappedJSClass.cpp 35 xul.dll nsXPCWrappedJS::CallMethod(unsigned short, XPTMethodDescriptor const*, nsXPTCMiniVariant*) js/xpconnect/src/XPCWrappedJS.cpp 36 xul.dll PrepareAndDispatch xpcom/reflect/xptcall/md/win32/xptcstubs_x86_64.cpp 37 xul.dll SharedStub xpcom/reflect/xptcall/md/win32/xptcstubs_asm_x86_64.asm 38 xul.dll nsObserverList::NotifyObservers(nsISupports*, char const*, wchar_t const*) xpcom/ds/nsObserverList.cpp 39 xul.dll nsObserverService::NotifyObservers(nsISupports*, char const*, wchar_t const*) xpcom/ds/nsObserverService.cpp 40 xul.dll mozilla::dom::ContentChild::RecvShutdown() dom/ipc/ContentChild.cpp 41 xul.dll mozilla::dom::PContentChild::OnMessageReceived(IPC::Message const&) obj-firefox/ipc/ipdl/PContentChild.cpp 42 xul.dll mozilla::ipc::MessageChannel::OnMaybeDequeueOne() ipc/glue/MessageChannel.cpp 43 xul.dll RunnableMethod<SoftwareDisplay, void ( SoftwareDisplay::*)(void), Tuple0>::Run() ipc/chromium/src/base/task.h 44 xul.dll MessageLoop::DoWork() ipc/chromium/src/base/message_loop.cc 45 xul.dll mozilla::ipc::DoWorkRunnable::Run() ipc/glue/MessagePump.cpp 46 xul.dll nsThread::ProcessNextEvent(bool, bool*) xpcom/threads/nsThread.cpp 47 xul.dll mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) ipc/glue/MessagePump.cpp 48 xul.dll mozilla::ipc::MessagePumpForChildProcess::Run(base::MessagePump::Delegate*) ipc/glue/MessagePump.cpp 49 xul.dll MessageLoop::RunHandler() ipc/chromium/src/base/message_loop.cc 50 xul.dll MessageLoop::Run() ipc/chromium/src/base/message_loop.cc 51 xul.dll nsBaseAppShell::Run() widget/nsBaseAppShell.cpp 52 xul.dll nsAppShell::Run() widget/windows/nsAppShell.cpp 53 xul.dll XRE_RunAppShell toolkit/xre/nsEmbedFunctions.cpp 54 xul.dll mozilla::ipc::MessagePumpForChildProcess::Run(base::MessagePump::Delegate*) ipc/glue/MessagePump.cpp 55 xul.dll MessageLoop::RunHandler() ipc/chromium/src/base/message_loop.cc 56 xul.dll MessageLoop::Run() ipc/chromium/src/base/message_loop.cc 57 xul.dll XRE_InitChildProcess toolkit/xre/nsEmbedFunctions.cpp 58 plugin-container.exe content_process_main(int, char** const) ipc/contentproc/plugin-container.cpp 59 plugin-container.exe wmain toolkit/xre/nsWindowsWMain.cpp 60 plugin-container.exe __tmainCRTStartup f:/dd/vctools/crt/crtw32/startup/crt0.c:255 61 kernel32.dll BaseThreadInitThunk 62 ntdll.dll RtlUserThreadStart
Component: Untriaged → Networking: JAR
Product: Firefox → Core
Version: Trunk → 41 Branch
Crash Signature: [@ nsZipArchive::GetDataOffset(nsZipItem*)] → [@ nsZipArchive::GetDataOffset(nsZipItem*)] [@ nsZipArchive::GetDataOffset]
https://crash-stats.mozilla.com/report/index/2614575a-ffd3-4114-aa6f-9b8b02160106 Win7, 64bit w/ FF46.0a1, 64bit Crashing Thread (0) Frame Module Signature Source 0 xul.dll nsZipArchive::GetDataOffset(nsZipItem*) modules/libjar/nsZipArchive.cpp 1 xul.dll nsZipArchive::GetData(nsZipItem*) modules/libjar/nsZipArchive.cpp 2 xul.dll nsJARInputStream::InitFile(nsJAR*, nsZipItem*) modules/libjar/nsJARInputStream.cpp 3 xul.dll nsJAR::GetInputStreamWithSpec(nsACString_internal const&, nsACString_internal const&, nsIInputStream**) modules/libjar/nsJAR.cpp 4 xul.dll nsJARInputThunk::Init() modules/libjar/nsJARChannel.cpp 5 xul.dll nsJARChannel::CreateJarInput(nsIZipReaderCache*, nsJARInputThunk**) modules/libjar/nsJARChannel.cpp 6 xul.dll nsJARChannel::Open(nsIInputStream**) modules/libjar/nsJARChannel.cpp 7 xul.dll mozJSComponentLoader::ObjectForLocation(ComponentLoaderInfo&, nsIFile*, JS::MutableHandle<JSObject*>, JS::MutableHandle<JSScript*>, char**, bool, JS::MutableHandle<JS::Value>) js/xpconnect/loader/mozJSComponentLoader.cpp 8 xul.dll mozJSComponentLoader::ImportInto(nsACString_internal const&, JS::Handle<JSObject*>, JSContext*, JS::MutableHandle<JSObject*>) js/xpconnect/loader/mozJSComponentLoader.cpp 9 xul.dll mozJSComponentLoader::Import(nsACString_internal const&, JS::Handle<JS::Value>, JSContext*, unsigned char, JS::MutableHandle<JS::Value>) js/xpconnect/loader/mozJSComponentLoader.cpp 10 xul.dll nsXPCComponents_Utils::Import(nsACString_internal const&, JS::Handle<JS::Value>, JSContext*, unsigned char, JS::MutableHandle<JS::Value>) js/xpconnect/src/XPCComponents.cpp 11 xul.dll XPTC__InvokebyIndex xpcom/reflect/xptcall/md/win32/xptcinvoke_asm_x86_64.asm 12 @0x28b8cf 13 xul.dll XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*) js/xpconnect/src/XPCWrappedNativeJSOps.cpp 14 xul.dll js::Invoke(JSContext*, JS::CallArgs const&, js::MaybeConstruct) js/src/vm/Interpreter.cpp 15 xul.dll Interpret js/src/vm/Interpreter.cpp 16 xul.dll js::RunScript(JSContext*, js::RunState&) js/src/vm/Interpreter.cpp 17 xul.dll js::Invoke(JSContext*, JS::CallArgs const&, js::MaybeConstruct) js/src/vm/Interpreter.cpp 18 xul.dll JS_CallFunctionValue(JSContext*, JS::Handle<JSObject*>, JS::Handle<JS::Value>, JS::HandleValueArray const&, JS::MutableHandle<JS::Value>) js/src/jsapi.cpp 19 xul.dll nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJS*, unsigned short, XPTMethodDescriptor const*, nsXPTCMiniVariant*) js/xpconnect/src/XPCWrappedJSClass.cpp 20 xul.dll nsXPCWrappedJS::CallMethod(unsigned short, XPTMethodDescriptor const*, nsXPTCMiniVariant*) js/xpconnect/src/XPCWrappedJS.cpp 21 xul.dll PrepareAndDispatch xpcom/reflect/xptcall/md/win32/xptcstubs_x86_64.cpp 22 xul.dll SharedStub xpcom/reflect/xptcall/md/win32/xptcstubs_asm_x86_64.asm 23 xul.dll nsObserverList::NotifyObservers(nsISupports*, char const*, wchar_t const*) xpcom/ds/nsObserverList.cpp 24 xul.dll nsObserverService::NotifyObservers(nsISupports*, char const*, wchar_t const*) xpcom/ds/nsObserverService.cpp 25 xul.dll mozilla::dom::ContentChild::RecvShutdown() dom/ipc/ContentChild.cpp 26 xul.dll mozilla::dom::PContentChild::OnMessageReceived(IPC::Message const&) obj-firefox/ipc/ipdl/PContentChild.cpp 27 xul.dll mozilla::ipc::MessageChannel::DispatchAsyncMessage(IPC::Message const&) ipc/glue/MessageChannel.cpp 28 xul.dll mozilla::ipc::MessageChannel::DispatchMessageW(IPC::Message const&) ipc/glue/MessageChannel.cpp 29 xul.dll mozilla::ipc::MessageChannel::OnMaybeDequeueOne() ipc/glue/MessageChannel.cpp 30 xul.dll RunnableMethod<mozilla::ipc::MessageChannel, bool ( mozilla::ipc::MessageChannel::*)(void), mozilla::Tuple<> >::Run() ipc/chromium/src/base/task.h 31 xul.dll MessageLoop::DoWork() ipc/chromium/src/base/message_loop.cc 32 xul.dll mozilla::ipc::DoWorkRunnable::Run() ipc/glue/MessagePump.cpp 33 xul.dll nsThread::ProcessNextEvent(bool, bool*) xpcom/threads/nsThread.cpp 34 xul.dll mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) ipc/glue/MessagePump.cpp 35 xul.dll mozilla::ipc::MessagePumpForChildProcess::Run(base::MessagePump::Delegate*) ipc/glue/MessagePump.cpp 36 xul.dll MessageLoop::RunHandler() ipc/chromium/src/base/message_loop.cc 37 xul.dll MessageLoop::Run() ipc/chromium/src/base/message_loop.cc 38 xul.dll nsBaseAppShell::Run() widget/nsBaseAppShell.cpp 39 xul.dll nsAppShell::Run() widget/windows/nsAppShell.cpp 40 xul.dll XRE_RunAppShell toolkit/xre/nsEmbedFunctions.cpp 41 xul.dll mozilla::ipc::MessagePumpForChildProcess::Run(base::MessagePump::Delegate*) ipc/glue/MessagePump.cpp 42 xul.dll MessageLoop::RunHandler() ipc/chromium/src/base/message_loop.cc 43 xul.dll MessageLoop::Run() ipc/chromium/src/base/message_loop.cc 44 xul.dll XRE_InitChildProcess toolkit/xre/nsEmbedFunctions.cpp 45 plugin-container.exe wmain toolkit/xre/nsWindowsWMain.cpp 46 plugin-container.exe __tmainCRTStartup f:/dd/vctools/crt/crtw32/startup/crt0.c:255 Ø 47 kernel32.dll kernel32.dll@0x159dc Ø 48 ntdll.dll ntdll.dll@0x2a630
Blocks: shutdownkill
status-firefox46: --- → affected
Whiteboard: ShutDownKill
From the crash signature nsZipArchive::GetDataOffset, the current affected versions are: - Nightly: 47 - Aurora: 46 - Beta: 44.0b1 - Release: 44.0
Whiteboard: ShutDownKill → ShutDownKill [necko-backlog]
https://crash-stats.mozilla.com/signature/?product=Firefox&signature=nsZipArchive%3A%3AGetDataOffset
status-firefox47: --- → affected
status-firefox48: --- → ?
status-firefox49: --- → ?
status-thunderbird_esr38: --- → affected
OS: Windows 7 → All
Hardware: x86_64 → All
Whiteboard: ShutDownKill [necko-backlog] → ShutDownKill, [necko-backlog]
Updating crash signature to reflect changes to signature generation made in bug 1269817 (although reports older than a week will not be reprocessed).
Crash Signature: [@ nsZipArchive::GetDataOffset(nsZipItem*)] [@ nsZipArchive::GetDataOffset] → [@ IPCError-browser | ShutDownKill ]
https://crash-stats.mozilla.com/report/index/b3036087-fc4b-4394-8d29-f8f6f2160913 Crashing Thread (0) Frame Module Signature Source 0 xul.dll nsZipArchive::GetDataOffset(nsZipItem*) modules/libjar/nsZipArchive.cpp:893 1 xul.dll nsZipArchive::GetData(nsZipItem*) modules/libjar/nsZipArchive.cpp:914 2 xul.dll nsZipCursor::nsZipCursor(nsZipItem*, nsZipArchive*, unsigned char*, unsigned int, bool) modules/libjar/nsZipArchive.cpp:1197 3 xul.dll nsZipItemPtr_base::nsZipItemPtr_base(nsZipArchive*, char const*, bool) modules/libjar/nsZipArchive.cpp:1278 4 xul.dll zlib_alloc js/src/vm/Compression.cpp:17 5 xul.dll mozilla::scache::`anonymous namespace'::GetBufferFromZipArchive startupcache/StartupCache.cpp:292 6 xul.dll ReadCachedScript(mozilla::scache::StartupCache*, nsACString_internal&, JSContext*, nsIPrincipal*, JS::MutableHandle<JSScript*>) js/xpconnect/loader/mozJSLoaderUtils.cpp:29 7 xul.dll mozJSComponentLoader::ObjectForLocation(ComponentLoaderInfo&, nsIFile*, JS::MutableHandle<JSObject*>, JS::MutableHandle<JSScript*>, char**, bool, JS::MutableHandle<JS::Value>) js/xpconnect/loader/mozJSComponentLoader.cpp:689 8 xul.dll mozJSComponentLoader::ImportInto(nsACString_internal const&, JS::Handle<JSObject*>, JSContext*, JS::MutableHandle<JSObject*>) js/xpconnect/loader/mozJSComponentLoader.cpp:1165
Crash Signature: [@ IPCError-browser | ShutDownKill ] → [@ nsZipArchive::GetDataOffset]
status-firefox48: ? → affected
status-firefox49: ? → affected
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P1
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: P1 → P3
status-firefox75: --- → affected
status-firefox76: --- → affected
QA Whiteboard: qa-not-actionable

Since the crash volume is low (less than 5 per week), the severity is downgraded to S3. Feel free to change it back if you think the bug is still critical.

For more information, please visit auto_nag documentation.

Severity: critical → S3

This appears to be a bounds-overrun due to (most likely) a corrupt jar file. Comment from a user indicates it's a repeatable startup crash for them (Mac).

Most crashes are Mac ESR78; the crashes are from Android 94+, and Mac 106. (plus a single Mac 80 crash).

uint32_t len = mFd->mLen;
  const uint8_t* data = mFd->mFileData;
  offset = aItem->LocalOffset();

  if (len < ZIPLOCAL_SIZE || offset > len - ZIPLOCAL_SIZE) return 0;
 // -- check signature before using the structure, in case the zip file is
  // corrupt
  ZipLocal* Local = (ZipLocal*)(data + offset);

->  if ((xtolong(Local->signature) != LOCALSIG)) return 0;

From that, one guess is that offset is corrupt, and we're indexing past the end of the data somehow. We shouldn't be, since there is a length check, and it subtracts the length of ZipLocal for the check. Perhaps there's an issue with the data for the Zip, and for some reason the memory referenced by mFd isn't accessible.

Assignee: nobody → rjesup
Group: core-security
status-firefox106: --- → affected
Keywords: csectype-bounds
Priority: P3 → --
Version: 41 Branch → Trunk

It's also very interesting that the errors are basically android-only now, and were (quite a while ago) Mac-only.

Windows crashes are all in shutdown.... very odd.

Crash Signature: [@ nsZipArchive::GetDataOffset] → [@ nsZipArchive::GetDataOffset] [@ shutdownhang | nsTHashtable<T>::s_HashKey | nsZipArchive::GetDataOffset ]
Group: core-security → network-core-security
Keywords: sec-high

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

For more information, please visit auto_nag documentation.

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

Comment on attachment 9301455 [details]
Bug 1164141: ZipArchive cleanup r=#necko

Security Approval Request

  • How easily could an exploit be constructed based on the patch?: Very hard
  • 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?: all
  • 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?: Trivial, no risk
  • How likely is this patch to cause regressions; how much testing does it need?: Very unlikely to cause regressions. Diagnostic patch (and returns error for a specific corruption, which we don't think is happening)
  • Is Android affected?: Yes
Attachment #9301455 - Flags: sec-approval?

Comment on attachment 9301455 [details]
Bug 1164141: ZipArchive cleanup r=#necko

Approved to land and request uplift if desired

Attachment #9301455 - Flags: sec-approval? → sec-approval+

ZipArchive cleanup r=necko-reviewers,valentin
https://hg.mozilla.org/integration/autoland/rev/1b442368d5670a54cb29aa8e7355824c2dfb3364
https://hg.mozilla.org/mozilla-central/rev/1b442368d567

Group: network-core-security → core-security-release
Status: NEW → RESOLVED
Closed: 3 years ago
status-firefox108: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 108 Branch

Since nightly and release are affected, beta will likely be affected too.
For more information, please visit auto_nag documentation.

status-firefox107: --- → affected

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

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

For more information, please visit auto_nag documentation.

Flags: needinfo?(rjesup)

IMO, we should let this bake a cycle rather than trying to get it into Beta right before RC week. That said, are we planning to handle any follow-up work in a new bug at this point (given that this patch seems more diagnostic in nature)?

status-firefox106: affected → wontfix
status-firefox107: affected → wontfix
status-firefox41: affected → wontfix
status-firefox46: affected → wontfix
status-firefox47: affected → wontfix
status-firefox48: affected → wontfix
status-firefox49: affected → wontfix
status-firefox75: affected → wontfix
status-firefox76: affected → wontfix
status-firefox-esr102: --- → affected
status-thunderbird_esr38: affected → wontfix

This is almost entirely diagnostic (though it fixes one unlikely edgecase). I'd let it ride on Nightly. And I forgot leave-open

Status: RESOLVED → REOPENED
Flags: needinfo?(rjesup)
Resolution: FIXED → ---
Status: REOPENED → NEW
status-firefox108: fixed → affected
Target Milestone: 108 Branch → ---

Comment on attachment 9301455 [details]
Bug 1164141: ZipArchive cleanup r=#necko

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration: Cleanup patch (which I wouldn't nominate), but adds one small fix and diagnostic asserts (though that will have no impact on ESR).
  • User impact if declined: Missing one error case for corrupted files
  • Fix Landed on Version: 108
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): No functional changes other that returning an error for a specific type of corrupted file
Attachment #9301455 - Flags: approval-mozilla-esr102?

Comment on attachment 9301455 [details]
Bug 1164141: ZipArchive cleanup r=#necko

Needed for bug 1801102 to graft cleanly, no expected functional impact otherwise. Approved for 102.6esr.

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

Comment on attachment 9301455 [details]
Bug 1164141: ZipArchive cleanup r=#necko

Landed on ESR102. Removing the approval flag to get this off the needs-uplift radar.
https://hg.mozilla.org/releases/mozilla-esr102/rev/32629cc89898

Attachment #9301455 - Flags: approval-mozilla-esr102+
Priority: -- → P3
Whiteboard: ShutDownKill, [necko-backlog] → ShutDownKill, [necko-backlog][necko-priority-review]

Done a bunch of looking, nothing has come from it.

Keywords: stalled
Whiteboard: ShutDownKill, [necko-backlog][necko-priority-review] → ShutDownKill, [necko-backlog]

(In reply to Randell Jesup [:jesup] (needinfo me) from comment #11)

It's also very interesting that the errors are basically android-only now, and were (quite a while ago) Mac-only.

The Mac crashes are back. There are also still Android crashes. They appear to be two different things.

Android is crashing on a null dereference on the line "uint32_t len = mFd->mLen" -- mFd must be null. Is there a missing check that the archive was opened/initted successfully? I don't see how the caller could get an nsZipItem to pass in to GetDataOffset() if mFd were null.

The Mac crashes are still like comment 10 so they've gotten a little further than the Android crashes.

I'm adding a few null checks and diagnostic asserts in https://phabricator.services.mozilla.com/D178986
There are a few places like these these ones that don't really check if the zip item is null before using it (assuming the call to item->RealSize doesn't crash), but these don't really show up in the stack traces so there must be something else going on.

If we land the diagnostic patch we might get some more info regarding what's causing the issue.

Attachment #9301455 - Attachment is obsolete: true

https://crash-stats.mozilla.org/signature/?signature=shutdownhang%20%7C%20nsZipArchive%3A%3AGetDataOffset&date=%3E%3D2024-08-28T18%3A15%3A00.000Z&date=%3C2024-09-04T18%3A15%3A00.000Z&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&_columns=moz_crash_reason&_sort=-date&page=1
shows that the windows crashes are pretty much all breakpoints, with comments in MOZ_REASON of stuff like Shutdown hanging at step AppShutdown. Something is blocking the main-thread. Most have shutdown phase entries on the stack. OTOH the linux and (mostly) mac crashes almost entirely do not have shutdown phase stack entries

I got claude to have a look at this after I noticed that crashes don't seem to happen on Windows, which means the mmap fault handler was wrong, and it pointed out that the condition:
https://searchfox.org/firefox-main/rev/d6dfd9f8cd9717b03750cded8980ef61678fbc8b/mozglue/misc/MmapFaultHandler.h#86

if (ValidFD(fd) && fd->mMap) {                           \

doesn't hold for memory mapped handles, such as when we have nested archives.

It also turns out we were trying to debug this in bug 1583735, and still have CrashWithInfo crashes.
The fix seems to be changing that line to ValidFD(fd) && fd->mFileStart && fd->mTotalLen > 0

I'm currently trying to get a good gtest to actually reproduce this.

Crash Signature: [@ nsZipArchive::GetDataOffset] [@ shutdownhang | nsTHashtable<T>::s_HashKey | nsZipArchive::GetDataOffset ] → [@ nsZipArchive::GetDataOffset] [@ shutdownhang | nsTHashtable<T>::s_HashKey | nsZipArchive::GetDataOffset ] [@ MmapAccessScope::CrashWithInfo ] [@ <name omitted> | MmapAccessScope::CrashWithInfo]
See Also: → 1583735

Test crashes without patch, but works with it 🎉

Keywords: stalled

Comment on attachment 9544143 [details]
(secure)

Setting flag for valentin due to a bug in BMO!?

Attachment #9544143 - Flags: sec-approval?

Comment on attachment 9544142 [details]
(secure)

Security Approval Request

  • How easily could an exploit be constructed based on the patch?:

Not easy. The patch does 2 things:

  • Handle SIGBUS faults for even if fd->mMap is null. This is the case when the JAR archive is nested inside another one.
  • Removes the CrashWithInfo added to diagnose why the crashes were still happening.

The SIGBUS is triggered when the mmaped file is truncated, and then Firefox accesses the mmaped memory. The mapped memory range's shouldn't change, so nothing else should be allocated at that address.
Also, these JAR files should not normally change while Firefox is in use.

  • 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?: All
  • If not all supported branches, which bug introduced the flaw?: Long standing issue.
  • Do you have backports for the affected branches?: Yes
  • If not, how different, hard to create, and risky will they be?: N/A
  • How likely is this patch to cause regressions; how much testing does it need?: unlikely to cause regressions.
  • Is the patch ready to land after security approval is given?: Yes
  • Is Android affected?: Yes
Assignee: rjesup → valentin.gosu
Attachment #9544143 - Flags: sec-approval?
Attachment #9301455 - Flags: sec-approval+

Comment on attachment 9544142 [details]
(secure)

sec-approval+

Attachment #9544142 - Flags: sec-approval+

Comment on attachment 9544143 [details]
(secure)

hold off on landing the tests until after the fix ships

Attachment #9544143 - Flags: sec-approval?
Whiteboard: ShutDownKill, [necko-backlog] → ShutDownKill, [necko-backlog][reminder-test 2026-04-07]

The bug is marked as tracked for firefox148 (beta) and tracked for firefox149 (nightly). However, the bug still has low priority.

:ghess, could you please increase the priority 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?(ghess)
Flags: needinfo?(ghess)
Priority: P3 → P2
Whiteboard: ShutDownKill, [necko-backlog][reminder-test 2026-04-07] → ShutDownKill, [necko-triaged][reminder-test 2026-04-07][necko-priority-queue]

:valentin could you add uplift requests now for Beta and ESR140? So it's ready for me to uplift before Monday

Flags: needinfo?(valentin.gosu)

https://hg-edge.mozilla.org/mozilla-central/rev/ce08acfe1c6c

Status: NEW → RESOLVED
Closed: 3 years ago → 5 months ago
status-firefox149: affected → fixed
Flags: in-testsuite?
Resolution: --- → FIXED
Target Milestone: --- → 149 Branch
Flags: needinfo?(valentin.gosu)

firefox-beta Uplift Approval Request

  • User impact if declined: Crashes when accessing mmapped memory belonging to nested jar files that have been truncated.
  • Code covered by automated testing: no
  • Fix verified in Nightly: yes
  • Needs manual QE test: no
  • Steps to reproduce for manual QE testing: Attached unit test (that will land at a later date) reproduces the crash, and doesn't crash when the fix is applied.
  • Risk associated with taking this patch: low
  • Explanation of risk level: The fix makes it so we also catch the SIGBUS signal when the mMap pointer is null. This happens when accessing memory for an inner JAR file (nested in another one).
    With the crash mitigated, we can also remove the CrashWithInfo call which was added to debug why we still crash, even though we had a SIGBUS handler.
  • String changes made/needed: None
  • Is Android affected?: yes
Attachment #9545125 - Flags: approval-mozilla-beta?

firefox-esr140 Uplift Approval Request

  • User impact if declined: Crashes when accessing mmapped memory belonging to nested jar files that have been truncated.
  • Code covered by automated testing: no
  • Fix verified in Nightly: yes
  • Needs manual QE test: no
  • Steps to reproduce for manual QE testing: Attached unit test (that will land at a later date) reproduces the crash, and doesn't crash when the fix is applied.
  • Risk associated with taking this patch: low
  • Explanation of risk level: The fix makes it so we also catch the SIGBUS signal when the mMap pointer is null. This happens when accessing memory for an inner JAR file (nested in another one).
    With the crash mitigated, we can also remove the CrashWithInfo call which was added to debug why we still crash, even though we had a SIGBUS handler.
  • String changes made/needed: None
  • Is Android affected?: yes
Attachment #9545127 - Flags: approval-mozilla-esr140?
Attachment #9545125 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Attachment #9545127 - Flags: approval-mozilla-esr140? → approval-mozilla-esr140+
Keywords: reporter-external
Whiteboard: ShutDownKill, [necko-triaged][reminder-test 2026-04-07][necko-priority-queue] → ShutDownKill, [necko-triaged][reminder-test 2026-04-07][necko-priority-queue][adv-main148+]
QA Whiteboard: qa-not-actionable → [sec] [uplift] [qa-triage-done-c149/b148]

sec-high is overstating the risk: this is almost entirely a start-up crash, and we only use the jar: protocol with our own files (or web extensions that we have signed). Lowering to sec-moderate

Keywords: sec-high → sec-moderate
Whiteboard: ShutDownKill, [necko-triaged][reminder-test 2026-04-07][necko-priority-queue][adv-main148+] → ShutDownKill, [necko-triaged][reminder-test 2026-04-07][necko-priority-queue][adv-main148+] [adv-esr140.8+]
Alias: CVE-2026-2779

Couldn't this be an XPI file the user navigates to, Dan?

Flags: needinfo?(dveditz)

navigating to a .XPI would trigger an install which does not do any nested zips. Once an add-on is installed I don't know if there are any features that it could use that would open a nested zip file inside. Maybe? but requiring installing a malicious extension to trigger also lowers the priority to sec-moderate.

Flags: needinfo?(dveditz)

2 months ago, dveditz placed a reminder on the bug using the whiteboard tag [reminder-test 2026-04-07] .

valentin, please refer to the original comment to better understand the reason for the reminder.

Flags: needinfo?(valentin.gosu)
Whiteboard: ShutDownKill, [necko-triaged][reminder-test 2026-04-07][necko-priority-queue][adv-main148+] [adv-esr140.8+] → ShutDownKill, [necko-triaged][necko-priority-queue][adv-main148+] [adv-esr140.8+]

Queued test for landing.

Flags: needinfo?(valentin.gosu)
Pushed by valentin.gosu@gmail.com: https://github.com/mozilla-firefox/firefox/commit/8f7bdb0ef77f https://hg.mozilla.org/integration/autoland/rev/55a7b083cd3c Add test for mmapped inner JAR file that gets truncated and generates SIGBUS r=jesup
Regressions: 2031243
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: