Closed Bug 1628717 Opened 4 years ago Closed 3 years ago

Crash in [@ DllFreeSplMem]

Categories

(Core :: Printing: Setup, defect, P3)

All
Windows
defect

Tracking

()

RESOLVED INVALID
Tracking Status
firefox-esr68 --- wontfix
firefox75 --- wontfix
firefox76 --- wontfix
firefox77 --- wontfix

People

(Reporter: philipp, Unassigned)

Details

(Keywords: crash, csectype-wildptr, sec-high)

Crash Data

This bug is for crash report bp-9bebea1c-528d-4f61-8e2f-19e9b0200409.

Top 10 frames of crashing thread:

0 winspool.drv DllFreeSplMem 
1 winspool.drv GetDefaultPrinterW 
2 prncache.dll PrintCache::RefreshDefaultPrinter 
3 prncache.dll PrintCache::Store::CacheStore::Initialize 
4 prncache.dll PrintCache::Store::CacheStore::Create 
5 prncache.dll PrintCache::CacheControllerInternal::CacheControllerInternal 
6 prncache.dll PrintCache::CreateCacheController 
7 prnfldr.dll CPrintServer::CreateInstance 
8 prnfldr.dll CPrintCacheManager::CreateServer 
9 prnfldr.dll CPrintCacheManager::InternalGetServer 

this printing crash signature has started showing up from users on windows since mid-march and is happening across platforms.
presumably a windows or driver update could have caused this spike...

maybe related to bug 1602125? Maybe not, that wouldn't explain ESR crashes.

Not sure this is a "vulnerability" for us if it's buried this deep in the OS. In any case, seems to require code calling the native show print dialog so that user interaction caps it to sec-moderate.

Group: core-security → layout-core-security
Keywords: sec-moderate
Priority: -- → P3

(In reply to Daniel Veditz [:dveditz] from comment #1)

maybe related to bug 1602125? Maybe not, that wouldn't explain ESR crashes.

Not sure this is a "vulnerability" for us if it's buried this deep in the OS. In any case, seems to require code calling the native show print dialog so that user interaction caps it to sec-moderate.

I haven't looked in detail, but I think that user interaction block is only when the crash is during actual printing (for example an issue in the print driver) or possibly interaction with the print dialog.
If it is just the display of the print dialog that can trigger this, then can't a web page trigger that with window.print().

Flags: needinfo?(dveditz)

yes, you're right. I was thinking about "print preview" (another button push) because we used to have a ton of Layout crashes in there. This is the native dialog itself and pages can trigger that.

Flags: needinfo?(dveditz)
Keywords: sec-moderatesec-high
Group: layout-core-security → dom-core-security

jwatt: Do you have thoughts on this?

Flags: needinfo?(jwatt)

This doesn't feel very actionable, and reports include versions as low as 52 ESR. Potentially something that will go away if we decide to work on bug 133787, which is looking likely.

One maybe interesting data point is that they are all on Windows 10.0.14393, and no newer builds.

Flags: needinfo?(jwatt)
Keywords: stalled
Group: dom-core-security → layout-core-security
Flags: needinfo?(emilio)

Looking at the most recent crashes, there seem to be three "Buckets".

Bucket #1: The backtrace shows us calling into Windows EndDocImpl which ultimately calls into a pair of DLLs with brpri / breni naming, with either a "c" or "d" suffix in the DLL name, which we don't have stack information for.

e.g. brpri19d.dll/breni19d.dll:
bp-b29fb62c-fe46-4a1d-b428-07e200210915
bp-948f8162-db6e-424c-8b08-151b20210921
...and brpri19c.dll/breni19c.dll:
bp-0d4d25e6-b2d8-49b4-9dfd-1a3210211013
bp-c4f53805-bd1a-494b-9fe5-9504b0210926

Those ones feel like they could be a printer driver bug; though a google search for the DLL names turns up no results, which is a little surprising and means we don't know precisely where to turn. But in any case, those are harder to investigate due to the special DLL, so it may be worth setting those ones aside.

Bucket #2: Crashes where our GetDefaultPrinterName function calls directly into GetDefaultPrinterW from winspool.drv, which then crashes in DllFreeSplMem:
bp-c5cfd318-4e49-4397-825c-41f800210901
bp-b0cedf3d-721e-4f85-9ba5-ace370211002
bp-a00d6e93-8604-4dc8-bc1b-359dd0210824
bp-be2f8344-dd98-4075-aba1-6104a0210823
bp-20148520-28fd-4f10-9ded-6d0bc0210817
bp-1b41a8d1-e63f-4c13-b94b-29e200210811

Bucket #3: Crashes while we're showing the native print dialog (NativeShowPrintDialog), some varying number of stack levels deep into Windows DLLs, we ultimately hit a crash in DllFreeSplMem (again going through GetDefaultPrinterW at the innermost layer). I think this is the bucket that comment 0's crash report would fall into.
bp-4088a5be-2c8a-47ac-94d8-00c9b0211008 (~50 stack levels of Windows APIs here)
bp-0041c7c5-7578-406b-bef8-4c3f00210823 (only a few stack levels of Windows APIs here)

Bucket #2 seems like the most actionable from our end at this point.

FWIW, DllFreeSplMem seems to be a windows-dll-internal memory-management function to free memory that was previously allocated using DllAllocSplMem, based on this Wine API-reimplementation documentation:
https://source.winehq.org/WineAPI/DllFreeSplMem.html

Best guess here is that this is a bug in the Windows winspool.drv GetDefaultPrinterW API, where it internally mistakenly passes a bogus pointer to DllFreeSplMem, for some reason or another. It's hard to reason about this in the abstract, without seeing its source code, but given the low crash-volume, this is probably in some unexpected edge case, perhaps in a bail-out to handle some error condition.

(In reply to Sean Voisen (:svoisen) from comment #5)

One maybe interesting data point is that they are all on Windows 10.0.14393, and no newer builds.

This is an interesting observation, and it's still sort-of true!! Specifically: in my crash-report links from comment 6, Buckets #2 and #3 are still all on this single Windows version, which seems to be from 2016, based on
https://www.lifewire.com/windows-version-numbers-2625171

So it seems very likely that this category of crash is just an old Windows-internals print spooler bug, which has been fixed or worked around in newer versions.

Bucket #1 (the ones that involve the mysterious brpri/breni DLL) are all from a different version, Windows 10.0.19043, which I think is relatively recent (maybe the newest Windows 10 release). I found a blog post about it here:
https://www.xda-developers.com/microsoft-releases-windows-10-build-19043-1165-heres-whats-new/
That one mentions that in this specific version, "There’s only a single highlight in this release" which "fixes a vulnerability in the Windows Print Spooler, and it’s pretty much all that’s new in this release."

That sounds like the sort of change that could have somehow-introduced a crash in winspool.drv; and given the involvement of these mysterious ungoogleable br DLLs, I wonder if maybe those DLLs are malware which manifests as a rogue print driver, which is trying to exploit the now-fixed vulnerability and is now simply crashing instead of successfully exploiting that Windows vulnerability.

Note: in comment 6, I was looking back 3 months. If I look back a bit further (6 months of history, 28 total crashes), I found some additional crashes which don't involve that br DLL and which weren't from that old 10.0.14393 windows-version:

bp-80ace716-594b-49af-84be-38d630210714 (Windows 10.0.18363 ; note, the backtrace doesn't quite make sense)
bp-aea556fe-e98b-4c03-8a3a-472690210615 (Windows 10.0.18363; note, the backtrace doesn't show any Mozilla code and is mostly in an HP print driver I think)
bp-415c3e8c-2c4e-446b-bf9f-9896b0210624 (Windows 10.0.19043, nothing stands out as too notable in this one except that it's in Thunderbird ESR 78.11.0 and our crash-backtrace click-to-view-source links unfortunately don't seem to work)

I think all the other ones that I clicked through from digging back that far were still from that one particular old Windows version, 10.0.14393. So, this still seems to be largely-explained by a bug in that version.

Bottom line: this bug report is seeming like it's a combination of the following:
(1) an old Windows OS bug that's been fixed in newer versions.
(2) crashes from drivers and/or malware DLLs (with brpri19d.dll/breni19d.dll or brpri19c.dll/breni19c.dll in the backtrace)
(3) possibly some other extremely-rare Windows crash (e.g. that single last crash report that I linked above), which also seems like it could easily be a Windows bug, or somehow-a-mozilla-bug that's nonetheless been fixed since 78.)

So, I don't think it's worth tracking this as a Mozilla bug at this point. Calling it INVALID since it's nearly-or-entirely explained by bugs in other software (mostly that one specific old windows version)

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → INVALID

Since the bug is closed, the stalled keyword is now meaningless.
For more information, please visit auto_nag documentation.

Keywords: stalled
Flags: needinfo?(emilio)
Group: layout-core-security
You need to log in before you can comment on or make changes to this bug.