Heap corruption in crypt32?

[Dan Kegel]

I strolled down memory lane a bit, and revisited the Sandra
benchmark today, see
http://www.winehq.org/pipermail/wine-devel/2006-December/052821.html

Now the win2k version gets a lot farther.
To install, first do
  sh winetricks vcrun2005sp1 gdiplus
(Without native gdiplus, the installer complains you don't have it;
without vcrun2005sp1, you get a few errors like
fixme:actctx:parse_assembly_elem wrong version for assembly manifest.)

The installer claims to be happy, but one sees

err:module:import_dll Library CRYPTUI.dll (which is needed by
L"C:\\windows\\temp\\is-KH13O.tmp\\certmgr.exe") not found
err:module:LdrInitializeThunk Main exe initialization for
L"C:\\windows\\temp\\is-KH13O.tmp\\certmgr.exe" failed, status
c0000135
Could not get handle to service.

on the console.  Worse, when the app starts up, you get a heap error:

err:heap:HEAP_ValidateInUseArena Heap 0x7f000000: in-use arena
0x7f02e2e0 next block has PREV_FREE flag
err:heap:HEAP_ValidateInUseArena Heap 0x7f000000: bad back ptr
0x1c9ba51e for arena 0x7f02e798

I suppose that could be a result of cryptui being missing, but I ran
it under valgrind anyway.
This turned up interesting items like

==20325== Invalid read of size 1
==20325==    at 0x46F5E49: HEAP_CreateFreeBlock (heap.c:486)
==20325==    by 0x46F621D: HEAP_ShrinkBlock (heap.c:575)
==20325==    by 0x46F7979: RtlAllocateHeap (heap.c:1228)
==20325==    by 0x5C60B74: new_object (handle.c:441)
==20325==    by 0x5C6B1CD: new_key (rsaenh.c:830)
==20325==    by 0x5C6C9DB: RSAENH_CPImportKey (rsaenh.c:2464)
==20325==    by 0x4B4324A: CryptImportKey (crypt.c:1767)
==20325==    by 0x4F2DCDC: CRYPT_ImportRsaPublicKeyInfoEx (encode.c:3923)
==20325==    by 0x4F2DA3B: CryptImportPublicKeyInfoEx (encode.c:3955)
==20325==    by 0x4F183FA: CRYPT_VerifyCertSignatureFromPublicKeyInfo
(cert.c:1641)
==20325==    by 0x4F1B069: CryptVerifyCertificateSignatureEx (cert.c:1723)
==20325==    by 0x4F1EDCD: CRYPT_CheckSimpleChain (chain.c:744)
==20325==  Address 0x7f02ecf8 is not stack'd, malloc'd or (recently) free'd

quite early in the run (well before the heap errs).
Juan, what do you make of it?
Might this be a real bug in crypt32 or our heap?
- Dan