KUSER_SHARED_DATA

In a landscape where KASLR randomizes kernel addresses and pool isolation separates allocations, one kernel structure stubbornly refuses to move. KUSER_SHARED_DATA lives at the fixed virtual address 0xFFFFF78000000000 in kernel space and 0x7FFE0000 in user space on every Windows installation, every boot, every version since Windows NT. It is mapped at these addresses because user-mode code needs fast access to system time, tick count, and other frequently queried values without the overhead of a syscall. This fixed mapping makes KUSER_SHARED_DATA the one kernel address an attacker always knows, even with no information leak and full KASLR in effect.

This predictability has made KUSER_SHARED_DATA a recurring tool in kernel exploitation. Its role has evolved significantly over the years, from a code execution staging area on pre-SMEP systems to a data-only exploitation aid on modern hardware. Understanding both the historical and current uses clarifies why this structure appears in exploit chains across different eras of Windows kernel security.

Historical use: shellcode staging

Before Supervisor Mode Execution Prevention (SMEP) was introduced in Intel Ivy Bridge processors and enforced by Windows 8, kernel exploits commonly executed shellcode from user-mode pages. The kernel would follow a corrupted function pointer to a user-mode address, and the CPU would execute the code because no hardware mechanism prevented it.

KUSER_SHARED_DATA offered an alternative approach. The kernel-mode mapping of this structure was readable, writable, and executable on early Windows versions. An attacker could write shellcode to the user-mode mapping at 0x7FFE0000 + offset and then redirect kernel execution to the corresponding kernel-mode address at 0xFFFFF78000000000 + offset. Because both addresses mapped to the same physical pages, the shellcode written from user mode was immediately visible at the kernel address.

This technique had two advantages over direct user-mode shellcode execution. First, the kernel address was in kernel space, so it would not trigger SMEP even on systems where SMEP was hypothetically available. Second, the address was fixed and known, eliminating the need for an information leak to find where to redirect execution.

SMEP and the shift to data-only use

SMEP, available from Windows 8 onward on supported hardware, prevents the CPU from executing pages marked as User in the page tables. Since KUSER_SHARED_DATA is mapped with User permissions in most configurations, SMEP blocks code execution from this region. HVCI further reinforces this by preventing the creation of writable-executable kernel pages through hypervisor-enforced page table validation.

These mitigations ended the shellcode staging use case on modern systems. However, KUSER_SHARED_DATA remains valuable for data-only exploitation techniques.

Current use: information source and data staging

On current Windows versions, KUSER_SHARED_DATA serves several roles in exploitation.

Known-address anchor. When an attacker has an arbitrary write but no information leak, KUSER_SHARED_DATA provides a writable location at a predictable kernel address. Writing controlled data to this structure and then using it as a reference point for further exploitation steps (such as constructing fake structures that point to other fake structures within the shared data region) avoids the need for KASLR bypass as a prerequisite.

System information source. The structure contains system tick count, system time, processor features, NtMajorVersion/NtMinorVersion, and NtBuildNumber. An attacker with a kernel read primitive can extract the OS build number from KUSER_SHARED_DATA, which is necessary for selecting correct structure offsets for token swapping and other build-dependent techniques. This avoids calling NtQuerySystemInformation or reading the PEB, which may be monitored.

Fake structure staging. For exploitation techniques that require planting a fake kernel structure at a known address (such as a fake RTL_BITMAP for bit-manipulation primitives, or a fake _IOP_MC_BUFFER_ENTRY for I/O Ring setup), the writable region within KUSER_SHARED_DATA provides a location that does not require an information leak to address. The attacker writes the fake structure from user mode and references it by its known kernel address.

Limitations

The user-mode mapping at 0x7FFE0000 is read-only in the page tables, preventing user-mode code from writing to it directly on modern Windows. Writing to the structure requires either a kernel-mode write primitive or a PTE manipulation that changes the page permissions. This means KUSER_SHARED_DATA is useful as a write target only when the attacker already has some form of kernel write capability, which reduces its value as a bootstrapping primitive.

The structure contains many fields that are actively read by the kernel and user-mode libraries. Overwriting critical fields (like system time or processor features) can cause system instability or application crashes. Exploits must write to unused or padding regions within the structure to avoid side effects.

On systems with HVCI, the kernel-mode mapping of KUSER_SHARED_DATA may have restricted permissions that prevent code execution, even if SMEP alone would not (due to the User bit in the PTE). HVCI's hypervisor-level enforcement provides defense in depth against any remaining code execution scenarios.

Mitigations

SMEP (Windows 8+, hardware-dependent) prevents code execution from KUSER_SHARED_DATA pages by blocking execution of User-marked pages in kernel mode. This eliminates the shellcode staging use case.

HVCI (Windows 10+, opt-in; Windows 11 default on supported hardware) reinforces SMEP through hypervisor-level page table validation, preventing bypass through PTE manipulation on VBS-enabled systems.

Read-only user-mode mapping: The user-mode mapping at 0x7FFE0000 is read-only, preventing direct writes from user-mode code. Kernel write capability is needed to modify the structure.

No mitigation exists for the data-only use cases (fake structure staging, information source) because they exploit the structure's fixed address and writable kernel mapping, which are inherent to its design.