Skip to content
KitploitKITPLOIT
ToolsBlog
Submit
ToolsBlog
Submit

Hacking, PenTest, and Cybersecurity Tools for Your Security Arsenal!

Kitploit is a directory of hacking, cybersecurity, and pentesting tools. Discover the latest project updates to find vulnerabilities, analyze systems, automate testing, and strengthen your security.

··Feeds·Contact·Privacy·© 2026 Kitploit

Tool Directory

Categories

View all categories
Loading categories
CVE-2025-62821 — Microsoft HEIF Extension (msheif_store.dll) OOB-read | Kitploit
Tools/GitHubGitHub/hyunjungg/cve-2025-62821
Memory ForensicsVulnerability AnalysisExploitationReverse EngineeringFuzzingBinary Analysis
GitHubhyunjungg/cve-2025-62821

CVE-2025-62821

Microsoft HEIF Extension (msheif_store.dll) OOB-read

View Repository
10 months agoNot yet reviewed

Most Popular

View all →

Discover the most used tools by our community.

Explore all tools

Browse our collection of tools

View all tools →
Share

Microsoft HEIF Image Extensions (msheif_store.dll): Source-buffer under-allocation in CopyPixels path leads to out-of-bounds read and Access Violation (DoS)

When decoding a crafted HEIF image through WIC, the msheif codec allocates a 1-byte source buffer but later attempts to copy a very large amount of pixel data from that buffer during CopyPixels. The copy uses memmove with a size derived from stride × ROI height, without validating the source buffer’s actual length. This causes an out-of-bounds read and an immediate Access Violation (crash). In practice, opening or previewing the malicious HEIF causes a denial of service in any WIC consumer that routes through the HEIF Image Extensions.

Naming note: Variable names like roi_height are inferred from disassembly for readability and do not reflect vendor symbol names.

ProductMicrosoft HEIF Image Extensions
Modulemsheif_store.dll
OSWindows 11
Extension version1.2.22.0 (Microsoft.HEIFImageExtension_1.2.22.0_x64__8wekyb3d8bbwe\x64\msheif_store.dll)
  1. Root Cause Analysis

    a. Detailed description of the vulnerability

    • The decoding pipeline computes a large copy length for memmove based on image geometry (e.g., copy_size = stride * abs(roi_height)).
    • The source buffer that should hold the decoded frame/item data is under-allocated to 1 byte, because:
      • CHEIFStreamReader_ReadItemData calls CHEIFItemInfoEntry_GetDataSize to compute the item’s data length.
      • On a specific failure branch, CHEIFItemInfoEntry_GetDataSize returns success but leaves the computed size as 0.
      • CHEIFStreamReader_ReadItemData then calls MFCreateMemoryBuffer(0, &ppBuffer). Per MF behavior, this produces a buffer with a minimum allocation of 1 byte.
    • Downstream, CopyPixels validates destination buffer size but does not validate source buffer length vs. requested copy size before calling memmove.
    • Result: memmove(dst, src, large_size) reads far past the 1-byte src, faulting at the vectorized load.

    This bug is independently exacerbated if the image/ROI width is mis-parsed (e.g., 0x01000100 = 16,777,472), inflating stride and the final copy size. However, the core vulnerability is source-length not checked against the computed copy length.

root@kitploit:~
(7de0.78e4): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
msheif_store!DllCanUnloadNow+0x228b1d:
00007ffd`841bc45d c5fe6f02        vmovdqu ymm0,ymmword ptr [rdx] ds:000002b0`65be6ff0=c0

0:000> !heap -p -a rdx
    address 000002b065be6ff0 found in
    _DPH_HEAP_ROOT @ 2b05bed1000
    in busy allocation (  DPH_HEAP_BLOCK:         UserAddr         UserSize -         VirtAddr         VirtSize)
                             2b062c2f2d8:      2b065be6ff0                1 -      2b065be6000             2000
    ...
    00007ffe75b90563 MFPlat!operator new+0x0000000000000023
    00007ffe75b83d36 MFPlat!MFCreateMemoryBuffer+0x0000000000000056
    00007ffd840157b1 msheif_store!DllCanUnloadNow+0x0000000000081e71
		...

0:000> r r8
r8=0000000001000100

b. Code flow from input

root@kitploit:~
0:000> k
 # Child-SP          RetAddr               Call Site
00 0000005d`6a9aed98 00007ffe`6fdefcc2     msheif_store!DllCanUnloadNow+0x228b21
01 0000005d`6a9aeda0 00007ffe`6fcb3adc     msheif_store!DllCanUnloadNow+0x18c382
02 0000005d`6a9aee00 00007ffe`6fcb4513     msheif_store!DllCanUnloadNow+0x5019c
03 0000005d`6a9aeef0 00007ffe`6fcb96da     msheif_store!DllCanUnloadNow+0x50bd3
04 0000005d`6a9af0a0 00007fff`318551d5     msheif_store!DllCanUnloadNow+0x55d9a
05 0000005d`6a9af1a0 00007fff`318082eb     windowscodecs!CPyramidBase::CopyPixels+0xf5
06 0000005d`6a9af260 00007fff`31857e52     windowscodecs!CFormatConverter::CopyPixels+0x22b
07 0000005d`6a9af3e0 00007ff6`15fb0f5d     windowscodecs!CFormatConverterResolver::CopyPixels+0xc2
08 0000005d`6a9af480 00007ff6`15fb04ab     heif_decoder!HEIF_LoadBitmapFromMemory+0x34d [C:\\\\Users\\\\test\\\\source\\\\repos\\\\heif_decoder\\\\heif_decoder\\\\heif_decoder.cpp @ 256]
09 0000005d`6a9af670 00007ff6`15fb1754     heif_decoder!HEIF_FuzzMemory+0x9b [C:\\\\Users\\\\test\\\\source\\\\repos\\\\heif_decoder\\\\heif_decoder\\\\heif_decoder.cpp @ 357]
0a 0000005d`6a9af830 00007ff6`15fb3039     heif_decoder!wmain+0x394 [C:\\\\Users\\\\test\\\\source\\\\repos\\\\heif_decoder\\\\heif_decoder\\\\heif_decoder.cpp @ 524]
0b 0000005d`6a9afaa0 00007ff6`15fb2ee2     heif_decoder!invoke_main+0x39 [D:\\\\a\\\\_work\\\\1\\\\s\\\\src\\\\vctools\\\\crt\\\\vcstartup\\\\src\\\\startup\\\\exe_common.inl @ 91]
0c 0000005d`6a9afaf0 00007ff6`15fb2d9e     heif_decoder!__scrt_common_main_seh+0x132 [D:\\\\a\\\\_work\\\\1\\\\s\\\\src\\\\vctools\\\\crt\\\\vcstartup\\\\src\\\\startup\\\\exe_common.inl @ 288]
0d 0000005d`6a9afb60 00007ff6`15fb30ce     heif_decoder!__scrt_common_main+0xe [D:\\\\a\\\\_work\\\\1\\\\s\\\\src\\\\vctools\\\\crt\\\\vcstartup\\\\src\\\\startup\\\\exe_common.inl @ 331]
0e 0000005d`6a9afb90 00007fff`3847e8d7     heif_decoder!wmainCRTStartup+0xe [D:\\\\a\\\\_work\\\\1\\\\s\\\\src\\\\vctools\\\\crt\\\\vcstartup\\\\src\\\\startup\\\\exe_wmain.cpp @ 17]
0f 0000005d`6a9afbc0 00007fff`3939c34c     KERNEL32!BaseThreadInitThunk+0x17
10 0000005d`6a9afbf0 00000000`00000000     ntdll!RtlUserThreadStart+0x2c

Resolved internal calls (renamed for clarity):

root@kitploit:~
CWICHeifDecoderFrame::CopyPixels
 → CWICHeifBitmapSourceBase::CopyPixels_Transform
   → CWICHeifBitmapSourceBase::CopyPixels_Base
     → sub_7FFD8411FC40  // issues memmove
       → memmove         // AV (vmovdqu load from src)

c. Buffer size

  • Crafted HEIF that causes CHEIFItemInfoEntry_GetDataSize to take an early “success with size 0” path (e.g., when sub_7FFD8408B898 fails and the function returns success with sizeBuffer = 0).

  • Source buffer: Allocated via MFCreateMemoryBuffer(0) ⇒ 1 byte.

  • Copy size: Derived as copy_size = stride * abs(roi_height). With mis-parsed width (e.g., 0x01000100) and typical BPP, stride is enormous, leading to a very large copy_size.

  • Vulnerable call:

    root@kitploit:~
    __int64 sub_7FFD8411FC40(__m128i* dst, __int64 a2, __m128i* src, int a4,
                             unsigned int stride, unsigned int abs_roi_height)
    {
      if (src && dst) {
        if (stride == a2 && stride == a4) {
          // No validation that 'src' contains at least (stride * abs_roi_height) bytes
          memmove(dst, src, (size_t)abs_roi_height * stride); // AV here
        }
      }
    }
    
  • Why the source is 1 byte (allocation path):

    root@kitploit:~
    __int64 __fastcall CHEIFStreamReader_ReadItemData(__int64 *a1, __int64 *a2, IMFMediaBuffer **a3)
    {
      ppBuffer = 0i64;
      if ( v7(a2) )
      {
        *cbMaxLength = 0i64;
        result = (*(*a2 + 0xA0))(a2, cbMaxLength); // CHEIFItemInfoEntry_GetDataSize
        if ( result < 0 )
        {
          goto LABEL_10;
        }
        if ( *cbMaxLength > 0xC800000ui64 )
        {
          result = 0xC00D36BE;
          goto LABEL_23;
        }
        // cbMaxLength may still be 0 if GetDataSize returned success early
        result = MFCreateMemoryBuffer(cbMaxLength[0], &ppBuffer);
        if ( result < 0 )
        {
          goto LABEL_34;
        }
        ...
    }
    
    root@kitploit:~
    __int64 __fastcall CHEIFItemInfoEntry_GetDataSize(__int64 a1, unsigned __int64 *sizeBuffer)
    {
    
      if ( sizeBuffer )
      {
        *sizeBuffer = 0i64;
        DataLocationInfo = (*(*v5 + 0x78i64))(v5, 0x6D657461i64, &v32);
        if ( DataLocationInfo >= 0 )
        {
          v13 = v32;
          v14 = *(v32 + 0xF0);
          if ( v14 )
          {
            if ( !sub_7FFD8408B898((v14 + 0xC8), (a1 - 0x78), &v33, v31) )
            {
            // returns success (0/S_OK) without updating sizeBuffer
    	      // caller treats this as length=0 → MFCreateMemoryBuffer(0)
    	          DataLocationInfo = 0;
    	          goto LABEL_62;
    	        }
            v17 = v33;
            DataLocationInfo = CHEIFItemInfoEntry_GetDataLocationInfo(v5, v13, *(v33 + 16), &v29, &v30);
            if ( DataLocationInfo >= 0 )
            {
              for ( i = 0; ; ++i )
              {
                if ( i >= *v17 )
                {
                  *sizeBuffer = v6;
                  goto LABEL_62;
                }
                v21 = *(*(v17 + 8) + 24i64 * i + 16);
                }
                if ( v21 + v6 < v6 )
                  break;
                v6 += v21;
                DataLocationInfo = 0;
              }
    
             ...
             ...
    LABEL_62:
      sub_7FFD83F91AEC();
      return DataLocationInfo;
    }
    

d. Suggested fixes

In CopyPixels path, validate that the source buffer has at least stride * abs(roi_height) bytes (and that src_stride/src_height meet or exceed the requested region). If not, fail with WINCODEC_ERR_INSUFFICIENTBUFFER (or equivalent).

e. Analysis methodology (symbol reconstruction)

To make the call flow reviewable, we reconstructed internal function names in IDA from the codec’s own logging strings.

  • Goal. Identify human-readable function names for key routines (…CopyPixels_Base, …CopyPixels_Transform, CHEIFStreamReader::ReadItemData, etc.) to align the crash stack with the decompiled code.

  • Procedure:

    1. Find the logging helper: In the decompiler view of callers around the crash, locate a small helper that’s invoked with a

      constant string

      argument resembling a function name (e.g., "CWICHeifBitmapSourceBase::CopyPixels_Base").

      • In IDA: open the function at the crash, go one frame up, and inspect calls at function entry for a helper taking a string literal.
    2. Collect callers: Use xrefs to that helper to list all caller functions.

    3. Extract names: For each caller, open the decompiled view and read the helper’s second argument (the string literal). This string consistently contains the intended function name.

    4. Rename callers: In each caller, press N (Edit → Rename) and set the function name to the recovered string (e.g., CWICHeifBitmapSourceBase::CopyPixels_Base).

    5. Repeat for nearby frames until the entire crash chain has meaningful names.

Validation. After renaming, re-run through the call sites and confirm that the argument types/behavior match the labels (e.g., …CopyPixels_Base is where stride/ROI math and the eventual memmove call occur).

  1. Proof-of-Concept

  • prerequisites : HEIF Image Extensions from the Microsoft Store installed/enabled (needed for HEIC/HEIF decoding).

  • Steps to reproduce

    1. Download and save the attached PoC file (../access_violation_0000xxxxxxxxx461_00000xxxxxxxx6B0_1.heif) to a local folder.

    2. Ensure HEIF Image Extensions is installed (open Microsoft Store → search “HEIF Image Extensions” → Install).

    3. Open the PoC file with Microsoft Photos (double-click the file if Photos is the default, or Right-click → Open with → Photos).

  • Software Download Link

    HEIF Image Extensions (Microsoft Store) https://apps.microsoft.com/detail/9pmmsr1cgpwg?hl=en-US&gl=US

Download Tool