# Untrusted pointer dereference in native IPC

Pointers, sizes, or addresses from shared sections or IPC messages reaching memcpy, ComPtr assignment, or indirect calls unvalidated

_Area: Memory corruption and native code. Seen in 4 disclosed reports; latest 2026-08-06. Updated 2026-10-23._

## How it works
A privileged component (kernel driver, SYSTEM service, sandboxed broker) receives a pointer, address, or size from a lower-privileged sender through a shared section or IPC message. The code assumes the sender supplied a valid, trusted value and uses it directly: as a memcpy source/destination/size, as an object pointer handed to a smart-pointer assignment, or as an indirect-call target. The assumption that breaks is that data crossing the trust boundary is well-formed and points where the receiver expects. It does not, so the receiver dereferences or writes to an attacker-chosen address in its own higher-privileged context.

## Where it shows up
- Message handlers that read pointer/size fields from shared memory or LPC/RPC payloads and pass them straight to memcpy or indirect calls [E4](https://bugbountylibrary.com/r/p0%3ACVE-2020-0986.md).
- Smart-pointer assignment (e.g. ComPtr operator=) fed a pointer taken from a shared section [E1](https://bugbountylibrary.com/r/p0%3ACVE-2023-36033.md).
- Serialize/deserialize round-trips that restore fields the code just zeroed, including function pointers used in indirect calls [E2](https://bugbountylibrary.com/r/p0%3ACVE-2022-24521.md).
- URI/COM handlers that forward unvalidated path or UNC parameters into a privileged consumer [E3](https://bugbountylibrary.com/r/blog%3Ahuntress-com-blog-unpatched-ntlm-leak-windows-search-uri-handler.md).

## How to review
Trace every pointer, length, and address field from the trust boundary to its use. The invariant: before any dereference, memcpy, or indirect call, the value must be validated against the receiver's own address space and expected object type, or replaced by a receiver-controlled value. Check that sizes are bounded and buffers are receiver-owned. For serialize/deserialize paths, confirm security-critical fields (especially function pointers) cannot be overwritten by overlapping regions after being cleared [E2](https://bugbountylibrary.com/r/p0%3ACVE-2022-24521.md). For URI/COM handlers, confirm the parameter is validated before reaching the privileged consumer [E3](https://bugbountylibrary.com/r/blog%3Ahuntress-com-blog-unpatched-ntlm-leak-windows-search-uri-handler.md).

## Variants seen
- Shared-section pointer into ComPtr assignment in DWM, giving arbitrary object dereference [E1](https://bugbountylibrary.com/r/p0%3ACVE-2023-36033.md).
- Zeroed function pointer restored by encode/decode round-trip, then used in an indirect call [E2](https://bugbountylibrary.com/r/p0%3ACVE-2022-24521.md).
- Unvalidated UNC path in a URI handler leaking NTLM credentials [E3](https://bugbountylibrary.com/r/blog%3Ahuntress-com-blog-unpatched-ntlm-leak-windows-search-uri-handler.md).
- Raw LPC message pointers passed to memcpy for arbitrary write [E4](https://bugbountylibrary.com/r/p0%3ACVE-2020-0986.md).

## Impact and severity
Led to sandbox escape and elevation to SYSTEM [E1](https://bugbountylibrary.com/r/p0%3ACVE-2023-36033.md)[E4](https://bugbountylibrary.com/r/p0%3ACVE-2020-0986.md), kernel RIP control [E2](https://bugbountylibrary.com/r/p0%3ACVE-2022-24521.md), and credential leakage [E3](https://bugbountylibrary.com/r/blog%3Ahuntress-com-blog-unpatched-ntlm-leak-windows-search-uri-handler.md). Severity is high because the dereference happens in a more privileged context than the attacker's; arbitrary write or call control turns a low-integrity foothold into full compromise. Missing validation at the boundary is what makes it worse.

## Evidence
- E1: https://bugbountylibrary.com/r/p0%3ACVE-2023-36033.md
- E2: https://bugbountylibrary.com/r/p0%3ACVE-2022-24521.md
- E3: https://bugbountylibrary.com/r/blog%3Ahuntress-com-blog-unpatched-ntlm-leak-windows-search-uri-handler.md
- E4: https://bugbountylibrary.com/r/p0%3ACVE-2020-0986.md