Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Problem/Bug]: Crash calling native code when IDispatch argument is in wrong parameter slot #4102

Open
BeipDev opened this issue Oct 25, 2023 · 0 comments
Assignees
Labels
bug Something isn't working tracked We are tracking this work internally.

Comments

@BeipDev
Copy link

BeipDev commented Oct 25, 2023

What happened?

I have javascript in a WebView2 calling a native method in my app, like so:

Code in HTML:

  window.onload = function() {
    window.chrome.webview.hostObjects.options.defaultSyncProxy=true; // Happens with/without this present
    window.chrome.webview.hostObjects.client.SetOnDisplay(1, onDisplay); // This is fine
    window.chrome.webview.hostObjects.client.SetOnDisplay(1, 1); // web console shows Type mismatch error (as expected)
    window.chrome.webview.hostObjects.client.SetOnDisplay(onDisplay, onDisplay); // Crash happens in this case
  }

  function onDisplay() { }

The native method is this:
HRESULT SetOnDisplay([in] int id, [in] IDispatch *pDisp);

The crash is: Exception thrown at 0x5FBECD48 (EmbeddedBrowserWebView.dll) in MyApp.exe: 0xC0000005: Access violation writing location 0x00000004.

The callstack is:

 	EmbeddedBrowserWebView.dll!embedded_browser_webview_current::internal::RemoteObjectProxy::Invoke(long,struct _GUID const &,unsigned long,unsigned short,struct tagDISPPARAMS *,struct tagVARIANT *,struct tagEXCEPINFO *,unsigned int *)	Unknown
 	oleaut32.dll!ExtractValueProperty()	Unknown
 	oleaut32.dll!_VariantChangeTypeEx@20()	Unknown
 	oleaut32.dll!_CoerceArg@32()	Unknown
 	oleaut32.dll!CTypeInfo2::GetInvokeArgs()	Unknown
 	oleaut32.dll!CTypeInfo2::Invoke(void *,long,unsigned short,struct tagDISPPARAMS *,struct tagVARIANT *,struct tagEXCEPINFO *,unsigned int *)	Unknown
>	MyApp.exe!OM::Dispatch<OM::IWebView>::Invoke(long id, const _GUID & riid, unsigned long lcid, unsigned short wFlg, tagDISPPARAMS * pdp, tagVARIANT * pvr, tagEXCEPINFO * pei, unsigned int * pu) Line 153	C++

Looking at the disassembly, it looks like the proxy is missing a nullptr check inside the RemoteObjectProxy Invoke? (happens the same in x64 and x86):

5FBECD3A  call        embedded_browser_webview_current::internal::RemoteObjectProxy::Invoke (5FBECD80h)  
5FBECD3F  mov         ebx,eax  
5FBECD41  jmp         embedded_browser_webview_current::internal::RemoteObjectProxy::Invoke+120h (5FBECD70h)  
5FBECD43  mov         edi,dword ptr [ebp+24h]  
5FBECD46  xor         ebx,ebx  

5FBECD48  mov         dword ptr [edi+4],ebx   // CRASH IS HERE

5FBECD4B  mov         dword ptr [edi],ebx  
5FBECD4D  push        offset string L"Function has no prop"... (5FDF09B8h)  
5FBECD52  call        dword ptr [__imp__SysAllocString@4 (5FE553BCh)]  
5FBECD58  mov         dword ptr [edi+8],eax  
5FBECD5B  mov         dword ptr [edi+0Ch],ebx  
5FBECD5E  mov         dword ptr [edi+10h],ebx  
5FBECD61  mov         dword ptr [edi+18h],ebx  
5FBECD64  mov         dword ptr [edi+1Ch],80070005h  
5FBECD6B  mov         ebx,80020009h

Importance

Important. My app's user experience is significantly compromised.

Runtime Channel

Stable release (WebView2 Runtime)

Runtime Version

118.0.2088.61

SDK Version

1.0.2088.41

Framework

Win32

Operating System

Windows 11

OS Version

10.0.22621.2428

Repro steps

Basically with any native method that can take an IDispatch that refers to a Javascript callback.

If you have any other parameters that are not IDispatch type, putting one of these parameters in the wrong spot will crash vs give a type mismatch error.

The 'What Happened?' above should show it clearly.

Regression

No, this never worked

Last working version (if regression)

No response

AB#47273803

@BeipDev BeipDev added the bug Something isn't working label Oct 25, 2023
@vbryh-msft vbryh-msft added the tracked We are tracking this work internally. label Oct 27, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working tracked We are tracking this work internally.
Projects
None yet
Development

No branches or pull requests

2 participants