Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=993

We have encountered Windows kernel crashes in the internal nt!nt!HvpGetBinMemAlloc and nt!ExpFindAndRemoveTagBigPages functions while loading corrupted registry hive files. We believe both crashes to be caused by the same bug. Examples of crash log excerpts generated after triggering the bug are shown below:

---
PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced.  This cannot be protected by try-except.
Typically the address is just plain bad or it is pointing at freed memory.
Arguments:
Arg1: a2b23004, memory referenced.
Arg2: 00000000, value 0 = read operation, 1 = write operation.
Arg3: 817f7f04, If non-zero, the instruction address which referenced the bad memory
	address.
Arg4: 00000000, (reserved)

Debugging Details:
------------------

[...]

STACK_TEXT:  
a3c0b70c 818b68d0 a06529c8 a0652fd8 a06529c8 nt!HvpGetBinMemAlloc+0x8
a3c0b73c 817f113e 00000001 80000580 80000578 nt!HvFreeHive+0x11c
a3c0b798 817c4fac a3c0b828 00000002 00000000 nt!CmpInitializeHive+0x5e6
a3c0b85c 817c5d91 a3c0bbb8 00000000 a3c0b9f4 nt!CmpInitHiveFromFile+0x1be
a3c0b9c0 817cdaba a3c0bbb8 a3c0ba88 a3c0ba0c nt!CmpCmdHiveOpen+0x50
a3c0bacc 817c63c4 a3c0bb90 a3c0bbb8 00000010 nt!CmLoadKey+0x459
a3c0bc0c 8165cdb6 002efa0c 00000000 00000010 nt!NtLoadKeyEx+0x56c
a3c0bc0c 77796c74 002efa0c 00000000 00000010 nt!KiSystemServicePostCall
WARNING: Frame IP not in any known module. Following frames may be wrong.
002efa74 00000000 00000000 00000000 00000000 0x77796c74
---

and

---
BAD_POOL_HEADER (19)
The pool is already corrupt at the time of the current request.
This may or may not be due to the caller.
The internal pool links must be walked to figure out a possible cause of
the problem, and then special pool applied to the suspect tags or the driver
verifier to a suspect driver.
Arguments:
Arg1: 00000022, 
Arg2: a9c14000
Arg3: 00000001
Arg4: 00000000

[...]

STACK_TEXT:  
a353b688 81760bf9 a9c14000 a353b6c0 a353b6b4 nt!ExpFindAndRemoveTagBigPages+0x1fd
a353b6f8 8184d349 a9c14000 00000000 a353b73c nt!ExFreePoolWithTag+0x13f
a353b708 818d48d9 a9c14000 00001000 a87bcfd8 nt!CmpFree+0x17
a353b73c 8180f13e 00000001 80000560 80000548 nt!HvFreeHive+0x125
a353b798 817e2fac a353b828 00000002 00000000 nt!CmpInitializeHive+0x5e6
a353b85c 817e3d91 a353bbb8 00000000 a353b9f4 nt!CmpInitHiveFromFile+0x1be
a353b9c0 817ebaba a353bbb8 a353ba88 a353ba0c nt!CmpCmdHiveOpen+0x50
a353bacc 817e43c4 a353bb90 a353bbb8 00000010 nt!CmLoadKey+0x459
a353bc0c 8167adb6 002bf614 00000000 00000010 nt!NtLoadKeyEx+0x56c
a353bc0c 77a36c74 002bf614 00000000 00000010 nt!KiSystemServicePostCall
WARNING: Frame IP not in any known module. Following frames may be wrong.
002bf67c 00000000 00000000 00000000 00000000 0x77a36c74
---

The issue reproduces on Windows 7 32- and 64-bit, and manifests itself both with and without Special Pools (but it is still advised to have the mechanism enabled). In order to reproduce the problem with the provided samples, it is necessary to load them with a dedicated program which calls the RegLoadAppKey() API.

The root cause of the crashes is unknown. It must be noted that in our test environment, reproduction has been very unreliable: the same hive could crash the system in one run, and then parse fine (or fail with an error) in 10 subsequent runs. In order to facilitate reproduction, I'm providing a high number of testcases which were seen to cause a bugcheck once or more, in hope that at least one of them will also reproduce externally.

################################################################################

On November 29, MSRC let us know that they were unable to reproduce a crash with the provided samples and report, and asked for more information and/or kernel crash dumps.

One day later, we've looked into the bug again and discovered that it wasn't sufficient to just load a single corrupted hive to trigger the bugcheck: instead, it is necessary to sequentially load several corrupted hives from the same path in the filesystem. MSRC confirmed that they could reliably reproduce the problem with this new information.

Since the additional detail is crucial to observe the symptoms of the bug and it was not included in the original report, I'm resetting the "Reported" date to November 30.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/41645.zip