---
name: Kernel Exploit Mitigations
slug: kernel-exploit-mitigations
category: Quality
description: Kernel Exploit Mitigations catalogs modern OS security mitigations like ASLR, DEP/NX, RELRO, stack canaries, CFI, sandboxing, and seccomp, along with detection methods and known bypass techniques. Use it when assessing target hardening or planning exploit mitigation bypasses.
github: "https://github.com/SnailSploit/Claude-Red/tree/main/Skills/exploit-dev/offensive-mitigations"
language: Python
stars: 2930
forks: 479
install: "npx degit https://github.com/SnailSploit/Claude-Red/tree/main/Skills/exploit-dev/offensive-mitigations ~/.claude/skills/offensive-mitigations"
installs_to: ~/.claude/skills/offensive-mitigations
source_path: Skills/exploit-dev/offensive-mitigations/SKILL.md
collection_size: 25
category_size: 1354
collection_url: "https://dirskills.com/collections/SnailSploit/Claude-Red"
added: 2026-08-17T07:09:55.458Z
last_synced: 2026-08-17T07:09:55.458Z
canonical_url: "https://dirskills.com/skills/kernel-exploit-mitigations"
---

# Kernel Exploit Mitigations

Kernel Exploit Mitigations catalogs modern OS security mitigations like ASLR, DEP/NX, RELRO, stack canaries, CFI, sandboxing, and seccomp, along with detection methods and known bypass techniques. Use it when assessing target hardening or planning exploit mitigation bypasses.

**Install:**

```bash
npx degit https://github.com/SnailSploit/Claude-Red/tree/main/Skills/exploit-dev/offensive-mitigations ~/.claude/skills/offensive-mitigations
```

## README

# SKILL: Modern Kernel Exploit Mitigations

## Metadata
- **Skill Name**: security-mitigations
- **Folder**: offensive-mitigations
- **Source**: https://github.com/SnailSploit/offensive-checklist/blob/main/mitigations.md

## Description
Security mitigation reference and bypass catalog: ASLR, DEP/NX, RELRO, stack canaries, CFI, sandboxing, seccomp. Covers both detection of enabled mitigations and known bypass techniques. Use when assessing target hardening or planning exploit mitigation bypasses.

## Trigger Phrases
Use this skill when the conversation involves any of:
`mitigations, ASLR bypass, DEP bypass, NX bypass, RELRO, stack canary bypass, CFI bypass, sandbox bypass, seccomp bypass, mitigation detection, checksec`

## Instructions for Claude

When this skill is active:
1. Load and apply the full methodology below as your operational checklist
2. Follow steps in order unless the user specifies otherwise
3. For each technique, consider applicability to the current target/context
4. Track which checklist items have been completed
5. Suggest next steps based on findings

---

## Full Methodology

# Modern Kernel Exploit Mitigations

## Memory-safety & Isolation

### Kernel Address Space Layout Randomization (KASLR)

- Randomizes memory addresses where the kernel and its components are loaded.
- Makes it difficult for attackers to predict kernel code and data locations.

#### Bypass Techniques

- **Information Leaks:** Exploiting vulnerabilities (e.g., uninitialized memory, side-channels) to leak kernel pointers and calculate the base address.
- **Side-Channel Attacks:** Using timing, cache, or other microarchitectural side channels to infer memory layout.
  - **Prefetch Cache Timing:** Measures access speed across the kASLR range (0xfffff80000000000 to 0xfffff80800000000, ~0x8000 iterations with 0x100000 alignment). The fastest access indicates a cached address, revealing the actual kernel base. Uses `rdtscp` for timing, `mfence` for memory barriers, and `prefetchnta`/`prefetcht2` for cache manipulation.
- **Targeting Non-Randomized Regions:** Exploiting data or code segments that are not fully randomized.
- **Brute-Force:** Feasible in environments with limited entropy (e.g., some 32-bit systems or specific configurations).
- **Intel LAM:** Linear Address Masking support exists on recent kernels/CPUs but may be disabled by default. Verify with kernel config, boot params, and CPU flags on your target.

### Kernel Page Table Isolation (KPTI)

- Linux:
  - Separates user-space and kernel-space page tables.
  - Mitigates the Meltdown vulnerability by preventing user-space access to kernel memory.

#### Bypass Techniques

- **Side-Channel Attacks:** Exploiting microarchitectural side channels (e.g., TLB timing, cache attacks) that leak information across the isolation boundary.
- **Hardware Vulnerabilities:** Exploiting CPU vulnerabilities (e.g., L1TF, MDS) that can bypass page table separation.
- **Implementation Flaws:** Bugs in the KPTI implementation itself.

#### Practitioner

- Linux: check status via `/sys/devices/system/cpu/vulnerabilities/*` and `dmesg | grep -i kpti`.
- Windows: verify meltdown/KVA shadowing with `Get-SpeculationControlSettings` PowerShell script from Microsoft.

### Supervisor Mode Access Prevention (SMAP)

- Linux:
  - Hardware feature preventing unintended kernel access to user-space memory.
  - Protects against attacks exploiting improper memory accesses.

#### Bypass Techniques

- **ROP/JOP Gadgets:** Finding instruction sequences (gadgets) within kernel code that disable SMAP temporarily (e.g., via `stac` instruction) before accessing user memory.
- **Data-Only Attacks:** Attacks that achieve their goal without directly accessing user-space data from the kernel inappropriately.
- **Kernel Information Leaks:** Combining with KASLR bypasses to find suitable gadgets.

#### Practitioner

- Linux: confirm with `grep smap /proc/cpuinfo` and `cat /proc/cpuinfo | grep 'smep\|smap'`.
- Check CR4 at runtime with `rdmsr`/`wrmsr` tools or `lscpu -e` on supported systems.

### Supervisor Mode Execution Protection (SMEP)

- Linux/Windows:
  - Hardware feature preventing execution of user-space code when in supervisor mode.
  - Located in bit 20 of the CR4 control register.
  - Blocks certain privilege escalation attacks that rely on executing shellcode in user-mode memory.

#### Bypass Techniques

- **ROP/JOP Chains:** Constructing code reuse chains entirely from existing kernel code, avoiding execution of user-space code.
- **Data-Only Attacks:** Exploiting vulnerabilities without needing to execute shellcode (e.g., overwriting kernel data structures).
- **Disabling SMEP:** Finding gadgets or techniques to modify the CR4 control register to disable SMEP.
- **Type Confusion Exploits:** Using type confusion vulnerabilities to gain control flow and build ROP chains for SMEP bypass.
- **Page Table Manipulation:** Modifying page table entries (PTEs) to change user pages to supervisor pages, making user-space code executable in kernel context.
- **Write-What-Where Primitives:** Using arbitrary write vulnerabilities to modify CR4 register or page table structures.

#### Practitioner

- Linux: `grep smep /proc/cpuinfo`; verify effective state via `dmesg | grep -i smep`.
- Windows: SMEP is enforced when Memory Integrity/HVCI is enabled on modern systems.

### Kernel Data Protection (KDP)

- Windows:
  - Marks certain kernel memory regions as read-only.
  - Prevents unauthorized modification of critical kernel data structures.

#### Practitioner

- Check with `Get-CimInstance -ClassName Win32_DeviceGuard` and `System Information → Device Guard properties` for KDP/HVCI/VBS.

### Memory Integrity (Core Isolation)

- Windows:
  - Uses virtualization and HVCI to prevent malicious code alteration.
  - Guards against code injection or execution in kernel mode.

#### Practitioner

- Enable/verify: Windows Security → Device Security → Core isolation details.
- PowerShell: `Get-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity | Select-Object Enabled`.

### Read-Only Data Sections (RODATA)

- Linux:
  - Marks specific kernel memory regions as read-only.
  - Prevents modification of critical data structures and code.

### Hardened Usercopy

- Linux:
  - Adds boundary checks to memory copy operations between user and kernel space.
  - Prevents buffer overflows and memory corruption during copy operations.

### Memory Tagging Extension (MTE)

- Linux (ARM):
  - Hardware-assisted memory safety feature to detect memory corruption bugs.
  - Mitigates use-after-free and buffer overflows at a hardware level.
  - Adopted as a production security feature in **Android 16 (March 2025)** with both asynchronous and synchronous detection modes available for apps.

#### How MTE Works

- **4-bit Tags:** Each 16-byte memory allocation receives a random 4-bit tag (values 0-15)
- **Pointer Tagging:** Upper bits of pointers store the allocation tag
- **Tag Checking:** Hardware validates pointer tag matches memory tag on every dereference
- **Fault on Mismatch:** Invalid access triggers `SIGSEGV` (sync mode) or logs asynchronously (async mode)

#### Bypass Techniques

- Tag Collision (Probabilistic): With only 4-bit tags (16 possible values), collision probability is high
  - Increase entropy with larger allocation pools; Android 16 uses tag rotation heuristics.
- Untagged Memory Regions: Not all memory is MTE-protected
  - Enable MTE on stack via `prctl(PR_MTE_TCF_SYNC, PR_TAGGED_ADDR_ENABLE)`.
- Asynchronous Mode Exploitation: Android's async mode delays fault reporting for performance
  - Use synchronous mode (`MTE_mode=sync`) for security-critical apps.
- Integer Overflow in Tag Calculation: MTE tags are derived from allocation size; overflow can corrupt tags
- Kernel-Space Bypass: MTE only protects userspace by default
  - Kernel allocations (`kmalloc`, `vmalloc`) don't use MTE (Android 16, Linux 6.8)
  - Kernel exploit primitives (KASLR leak, arbitrary write) unaffected
  - Syscall buffer handling may not validate tags
- JIT Code Execution: JIT-compiled code can bypass MTE checks

```asm
; Assembly gadget to create untagged pointer
mov x0, xzr          ; Zero out tag bits
orr x0, x0, #0x1000  ; Set address without tag
ldr x1, [x0]         ; Load from untagged pointer (no MTE check)
```

#### Exploitation Workflow:

1. Leak a tagged pointer
2. Strip tag bits (mask upper 8 bits)
3. Use untagged pointer for memory operations
4. MTE doesn't validate untagged accesses in some contexts

#### Practitioner

- Android: enable per‑app via Developer Options or `adb shell setprop persist.device_config.runtime_native_boot.mte_mode sync` (device‑specific).
- Linux: compile with `CONFIG_ARM64_MTE` and use `prctl(PR_SET_TAGGED_ADDR_CTRL, ...)` from user space.
- Verify MTE status: `cat /proc/cpuinfo | grep mte` and check `HWCAP2_MTE` in `getauxval(AT_HWCAP2)`
- Android 16+ apps: opt-in via manifest `<application android:memtagMode="sync">`

### Intel Linear Address Masking (LAM)

Intel allows software to use upper address bits for metadata, similar to ARM's Top Byte Ignore (TBI).

#### How LAM Works

- **LAM57:** Uses bits 62:57 (6 bits) for tags in 5-level paging
- **LAM48:** Uses bits 62:48 (15 bits) for tags in 4-level paging
- **Hardware Masking:** CPU ignores tagged bits during address translation
- **Use Cases:** Memory tagging, capability systems, garbage collection metadata
- **Vulnerability Classes:**

1. **Pointer Forge:** Attackers can craft tagged pointers without validation
2. **Info Leak Bypass:** Some sanitizers only check canonical addresses; LAM-tagged pointers pass checks
3. **Address Confusion:** Software assuming canonical addresses may mishandle LAM pointers

### Memory Sealing

- Linux:
  - `mseal()` permanently seals selected VMAs so permissions/mappings can no longer change—even by the owner (verify kernel version and libc support on your target).
  - Adopted by projects such as Chrome/glibc/BPF tool‑chains to seal JIT pages, locking down GOT/PLT and eBPF JIT regions (version‑specific; verify).

#### Bypass Techniques

- **Time‑of‑use Window:** Exploits must succeed before sealing.
- **Data‑only Abuse:** Still possible if the mapping remains writable.
- **Kernel Flaws:** Bugs in the `mseal()` path could bypass a seal.

#### Practitioner

- Verify `mseal` availability via `grep -R sys_mseal /proc/kallsyms` or kernel `symbols`.
- Userland: `prctl(PR_MSEAL, ...)` (glibc 2.41+ headers), check errno for `ENOSYS` on older kernels.

### Privileged Access Never (PAN)

- Linux (ARM):
  - Hardware feature preventing direct kernel access to user-space memory.
  - Similar concept to SMAP on x86, prevents certain data leakage/corruption bugs.

### Kernel DMA Protection

- Windows:
  - Uses IOMMU/VT-d to protect against malicious peripherals performing DMA attacks.
  - Prevents unauthorized memory access via hardware devices.

### Pluton Security Processor

- Windows:
  - Microsoft Pluton is increasingly deployed with newer platforms, replacing or augmenting discrete TPM 2.0 and hardware‑binding BitLocker keys, Secure Boot, and HVCI policies. Check OEM/SKU documentation for Copilot+ requirements.

#### Practitioner

- Check Pluton state in Device Manager → Security devices, or `tpm.msc` shows Pluton‑backed TPM if present.

### Memory Protection Keys (MPK)

- Linux:
  - Provides per-page memory permissions using hardware keys.
  - Allows fine-grained control over memory access rights.

#### Bypass Techniques

- **PKRU Register Manipulation**: Using gadgets to modify the Protection Key Rights Register.
- **Unprotected Memory**: Targeting memory regions not protected by MPK.
- **Implementation Bugs**: Exploiting flaws in the MPK implementation.
- **Side-Channel Attacks**: Using side channels to infer protected memory contents.

### Protection Keys for Supervisor (PKS)

- Linux/Intel:
  - Extends PKU to supervisor pages; the kernel flips page permissions via `wrmsr PKS_MSC*` without TLB flushes (Sapphire‑Rapids+).
  - Landed upstream in Linux 6.12.

#### Bypass Techniques

- **ROP/JOP `WRMSR` Gadgets** that flip PKS bits.
- **Unprotected Regions** outside a PKS domain.
- **CPU Errata** undermining isolation.

#### Practitioner

- Linux: enable with `CONFIG_X86_PKS`; verify via `dmesg | grep -i pks` and `/proc/cpuinfo` flags.

### Zero-Page Memory Allocation

- Linux/Windows:
  - Ensures memory pages are zeroed before allocation.
  - Prevents leakage of residual data.

### Zero-Page Mapping Removal

- Linux:
  - Removes zero page mapping to prevent NULL pointer dereference exploits.
  - Enhances memory safety.

### Init-On-Alloc and Init-On-Free and Init-Stack-All-Zero

- Linux:
  - Automatically zeroes memory when allocated or freed.
  - Prevents use-after-free and information leakage.

### TPM Bus Encryption

- Linux:
  - Recent kernels add support for stronger TPM transports over SPI/I²C on some platforms. Feature availability and defaults vary; verify in `dmesg` and driver configs for your device.

#### Practitioner

- Verify with `dmesg | grep -i tpm` and kernel config `CONFIG_TCG_TIS_SPI`/`_I2C` options; firmware must expose supported transports.

## Memory Safety Initiatives

### Rust in the Linux Kernel

- First‑class Rust support landed in Linux 6.1 (December 2022) and was declared production‑ready with Linux 6.6 (October 2023).
- In‑tree Rust drivers (e.g., NVMe, DRM simple‑display, Wi‑Fi) have so far exhibited zero memory‑safety bugs under continuous fuzzing, demonstrating the practical security benefit of memory‑safe languages.
- Ongoing work aims to extend Rust usage into networking, Android GKI modules, and scheduler subsystems, further shrinking the kernel's attack surface.

### Safer Windows Drivers with C++20 and Rust

- Starting in Windows 11 23H2, the Windows Driver Framework (WDF) officially supports both modern C++20 and a Rust projection (`windows‑drivers‑rs`) that wrap KMDF/WDF APIs with lifetime‑safe abstractions.
- Hardware vendors can now obtain WHQL signatures for C++20 or Rust kernels drivers, eliminating common lifetime and IRQL‑misuse bugs without sacrificing performance.

### CHERI / Morello (Experimental Capability Hardware)

- Arm's Morello evaluation platform (2022‑2025) runs a CHERI‑enabled Linux kernel that enforces pointer capabilities in user and kernel space, providing hardware‑enforced spatial and temporal memory safety.
- Although experimental, CHERI demonstrates a plausible post‑2025 path toward fundamentally safer C/C++ code with architectural support.

### memfd_secret (userland secret memory)

- Linux:
  - `memfd_secret` (Linux 5.14+) provides user‑mode pages hidden from other processes and the kernel direct mappings
  - Useful for protecting keys and ROP staging from accidental exposure; verify support via kernel config and `memfd_secret(2)`

## Virtualization-Based Security Enhancements

### Virtualization-Based Security (VBS)

- Windows:
  - Creates an isolated, secure memory region using hardware virtualization.
  - Protects sensitive system components and data from malware and exploits.

#### Bypass Techniques

- **Hypervisor Vulnerabilities:** Exploiting bugs in the underlying hypervisor (Hyper-V) to escape the VBS container.
- **Misconfiguration:** Weaknesses in VBS configuration or deployment.
- **Physical Access:** Hardware-level attacks (e.g., DMA attacks if not mitigated by Kernel DMA Protection).
- **Compromised Signed Components:** Exploiting vulnerabilities in trusted components running within VBS.

#### Practitioner

- Confirm VBS/HVCI: `Core isolation` settings or PowerShell `Get-CimInstance -ClassName Win32_DeviceGuard` (look for `VirtualizationBasedSecurityStatus` and `SecurityServicesConfigured`).

### AMD Secure Encrypted Virtualization – Secure Nested Paging (SEV‑SNP)

- Linux guest support since 6.11; provides full memory encryption + integrity with an SVSM.
- Shipping today in major cloud "confidential VM" SKUs.

### Intel Trust Domain Extensions (TDX)

- Guest driver landed in 6.11; host enablement queued for 6.16.
- Protects guest memory against a compromised hypervisor.

#### Practitioner

- Cloud: verify TDX/SEV‑SNP instance type (`Azure DCasv5/ECasv5`, `GCP C3`, `AWS C7g` variants); attest via platform‑specific tools (e.g., `az confcom attestation`).

### Arm Confidential Compute Architecture (CCA) Realms

- Realm VM support merged in 6.13 for Arm v9 CPUs, giving encrypted, isolated guest environments.

### Hypervisor-Enforced Code Integrity (HVCI)

- Windows:
  - Uses VBS to enforce code integrity checks on kernel-mode drivers and binaries.
  - Ensures only signed and verified code can execute in kernel mode.

#### Bypass Techniques

- **Signed Malicious Drivers:** Obtaining signing certificates (stolen or illicitly acquired) to sign malicious code.
- **Exploiting Allowed Drivers:** Finding vulnerabilities in legitimate, signed drivers already running on the system ("Bring Your Own Vulnerable Driver" - BYOVD).
- **Hypervisor Vulnerabilities:** Exploiting the underlying hypervisor (see VBS bypasses).
- **Configuration Issues:** Weaknesses in Code Integrity policies.

### Mode Based Execution Control (MBEC)

- Windows:
  - Ensures driver code can only be executed in kernel mode.
  - Available in hardware and software (emulated) forms.
  - Prevents user-mode execution of kernel code.

### Kernel Mode Code Integrity (KMCI)

- Windows:
  - Ensures kernel pages can only become executable with proper signing.
  - Enforces driver signing enforcement and vulnerable driver blocklists.
  - Implements software SMEP (Supervisor Mode Execution Prevention).
  - `DriverSiPolicy.p7b` now refreshes **weekly** via Windows Update and MEM Configuration Manager, accelerating the BYOVD blocklist cadence.

### User Mode Code Integrity (UMCI)

- Windows:
  - Ensures user mode pages can only become executable with proper signing.
  - CI validates the signaturees of EXE and DLL before allowing them to load.
  - Enforces protected processes and protected process light signature requirements
  - Enforces `/INTEGRITYCHECK` for `FIPS 140-2` modules
  - Exposed to consumers as _Smart App Control_ and businesses as _App Control for Business_.
  - Part of the Device Guard technology stack.

### Windows Defender System Guard

- Windows:
  - Monitors system integrity during boot and runtime.
  - Protects against rootkits and bootkits by verifying system integrity.

### Windows Defender Application Guard

- Windows:
  - Runs untrusted content in isolated containers.
  - Protects the host from potentially malicious websites and documents.

### Credential Guard

- Windows:
  - Uses VBS to isolate and protect credentials.
  - Prevents attacks like Pass-the-Hash or Pass-the-Ticket.

### Device Guard

- Windows:
  - Combines WDAC and virtualization-based security to lock down devices.
  - Ensures only trusted applications can run.

## OS Loader and Hotpatching Changes (Windows 11 24H2+)

- Recent Windows versions (24H2 and later) introduced changes that impact classic process injection techniques like Process Hollowing (RunPE).
- **Status:** Client Hotpatching availability and cadence depend on SKU/servicing channel. Validate GA status in current Microsoft documentation.
- Windows Server 2025 requires an Azure Arc subscription for hotpatch servicing.

### Impact on Process Hollowing (MEM_PRIVATE Payloads)

- **Root Cause 1 (Error `0xC0000141`):** Native Hotpatching support added a new function `RtlpInsertOrRemoveScpCfgFunctionTable` during process initialization (`LdrpInitializeProcess -> LdrpProcessMappedModule`). This function calls `ZwQueryVirtualMemory` with a new `MemoryImageExtensionInformation` class, which _only_ works on `MEM_IMAGE` memory regions.
  - Classic Process Hollowing stores the payload in `MEM_PRIVATE` memory (either by unmapping the original PE or allocating a new region).
  - The `ZwQueryVirtualMemory` call fails with `STATUS_I