Crash when PR_Lock NULL lock with Upek PasswordBank

RESOLVED INCOMPLETE

Status

()

Core
Plug-ins
--
critical
RESOLVED INCOMPLETE
7 years ago
5 years ago

People

(Reporter: Sean Leonard, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

7 years ago
User-Agent:       Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.2; OfficeLiveConnector.1.3; OfficeLivePatch.0.0; MS-RTC LM 8; .NET4.0C; InfoPath.3)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13

Firefox 3.6.13 (and prior 3.6 versions) crash occasionally when using the Upek (AuthenTec) PasswordBank extension for Firefox.

For reasons that follow, however, the problem appears to be related to Firefox itself, and not the Upek (AuthenTec) extension.

Upek Eikon is a fingerprint reader. It is used with Upek/AuthenTec's Protector Suite 2009. When the Protector Suite detects a website or window that could take a password, it flashes the window to alert the user that the user could swipe his or her finger to fill in the password forms.

A special extension called the "PasswordBank extension", available at
http://files.upek.com/GetPackage.asp?Key=OKXY231M11OA9655BJP7KI6U4U621KGD

helps the Protector Suite figure out specific forms on specific websites instead of treating Firefox like an undifferentiated window.

However, sometimes when the Protector Suite software detects a window other than the Firefox window, Firefox mysteriously crashes in the background. This is probably related to the Protector Suite password software sending a window message to Firefox that Firefox does not handle properly.

Reproducible: Sometimes

Steps to Reproduce:
1. Get some Upek hardware and software.
2. Open a Firefox window; use it a bit.
3. Open another window that could take passwords, such as a Windows password dialog.
4. Watch Firefox crash in plugin-container.exe in the background.

Actual Results:  
Firefox crashes in plugin-container.exe.

Expected Results:  
Firefox should not crash!

Here is the stack trace from Visual Studio:

In plugin-container.exe:

 	ntdll.dll!_RtlEnterCriticalSection@4()  + 0x12 bytes	
>	nspr4.dll!PR_Lock(PRLock * lock=0x00000000)  Line 234	C
 	xul.dll!mozilla::MutexAutoLock::MutexAutoLock(mozilla::Mutex & aLock={...})  Line 180 + 0x8 bytes	C++
 	xul.dll!mozilla::plugins::PluginInstanceChild::FlashThrottleMessage(HWND__ * aWnd=0x002303e2, unsigned int aMsg=1025, unsigned int aWParam=1, long aLParam=104354728, bool isWindowed=true)  Line 1418	C++
 	xul.dll!mozilla::plugins::PluginInstanceChild::WinlessHiddenFlashWndProc(HWND__ * hWnd=0x002303e2, unsigned int message=1025, unsigned int wParam=1, long lParam=104354728)  Line 1302	C++
 	user32.dll!_InternalCallWinProc@20()  + 0x23 bytes	
 	user32.dll!_UserCallWinProcCheckWow@32()  + 0xb7 bytes	
 	user32.dll!_DispatchMessageWorker@8()  + 0xed bytes	
 	user32.dll!_DispatchMessageW@4()  + 0xf bytes	
 	xul.dll!base::MessagePumpForUI::ProcessMessageHelper(const tagMSG & msg={...})  Line 368	C++
 	xul.dll!base::MessagePumpForUI::ProcessNextWindowsMessage()  Line 340 + 0xc bytes	C++
 	xul.dll!base::MessagePumpForUI::DoRunLoop()  Line 209 + 0x6 bytes	C++
 	xul.dll!base::MessagePumpWin::RunWithDispatcher(base::MessagePump::Delegate * delegate=0x00000000, base::MessagePumpWin::Dispatcher * dispatcher=0x0114fc6c)  Line 54	C++
 	xul.dll!base::MessagePumpWin::Run(base::MessagePump::Delegate * delegate=0x0114fcc0)  Line 78 + 0xc bytes	C++
 	xul.dll!MessageLoop::RunInternal()  Line 217	C++
 	xul.dll!MessageLoop::RunHandler()  + 0x1be841 bytes	C++
 	xul.dll!MessageLoop::Run()  Line 174	C++
 	xul.dll!base::Thread::ThreadMain()  Line 168	C++
 	xul.dll!`anonymous namespace'::ThreadFunc(void * closure=0x00602c08)  Line 27	C++
 	kernel32.dll!@BaseThreadInitThunk@12()  + 0x12 bytes	
 	ntdll.dll!___RtlUserThreadStart@8()  + 0x27 bytes	
 	ntdll.dll!__RtlUserThreadStart@8()  + 0x1b bytes	

As is obvious enough from the stack trace, PR_Lock() is taking a NULL pointer. That is not a PasswordBank bug--that is a Firefox bug.

The underlying message that causes this error is Winows Message 1025 (0x401). That could be a wide variety of underlying messages:
0401 
 
 1025 
 
 CBEM_INSERTITEMA 
 
0401 
 
 1025 
 
 DDM_DRAW 
 
0401 
 
 1025 
 
 DM_SETDEFID 
 
0401 
 
 1025 
 
 HKM_SETHOTKEY 
 
0401 
 
 1025 
 
 PBM_SETRANGE 
 
0401 
 
 1025 
 
 RB_INSERTBANDA 
 
0401 
 
 1025 
 
 SB_SETTEXTA 
 
0401 
 
 1025 
 
 TB_ENABLEBUTTON 
 
0401 
 
 1025 
 
 TBM_GETRANGEMIN 
 
0401 
 
 1025 
 
 TTM_ACTIVATE 
 
0401 
 
 1025 
 
 WM_CHOOSEFONT_GETLOGFONT 
 
0401 
 
 1025 
 
 WM_PSD_FULLPAGERECT 
 

I have not been able to understand the full source code, but whatever that message or window does, is related to the function:
void
PluginInstanceChild::FlashThrottleMessage(HWND aWnd,
                                          UINT aMsg,
                                          WPARAM aWParam,
                                          LPARAM aLParam,
                                          bool isWindowed)

which then attempts to take a lock on:
        MutexAutoLock lock(mAsyncCallMutex);

Hopefully that helps.
(Reporter)

Comment 1

7 years ago
Just to add to "Firefox crashes": specifically, plugin-container.exe crashes, all of the Firefox windows close, and eventually, firefox.exe goes away as well. I was under the impression that plugin-container.exe is supposed to isolates these kinds of crashes, but I guess not.
Component: General → Plug-ins
Product: Firefox → Core
QA Contact: general → plugins

Updated

5 years ago
Status: UNCONFIRMED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.