Most code-reuse exploits end the same way: a memory corruption bug lets the attacker overwrite a return address or function pointer, and the program jumps where the attacker chose. MITRE D3FEND names the countermeasure that signs pointers and checks the signature before use Pointer Authentication (D3-PAN), and defines it as "Comparing the cryptographic hash or derivative of a pointer's value to an expected value." It sits under the Harden tactic as a child of Application Hardening (D3-AH), beside Control Flow Integrity and Stack Frame Canary Validation. This card explains how pointer authentication works on Arm processors, why D3FEND gives it no ATT&CK mapping, how to turn it on in compilers, kernels and operating systems, how to check it is active, and the known bypass classes. It is written for platform, firmware and application security engineers who build or ship code for 64-bit Arm; the wider set of mitigations is in the Exploit Mitigations Guide.
Key takeaways
- A signature in the spare pointer bits. A Pointer Authentication Code (PAC) is computed from the pointer, a secret key and a context value and stored in unused high bits; it is checked before the pointer is used, so a tampered pointer faults.
- Hardware, compiler and OS all have to take part. The Arm architecture provides the instructions (from Armv8.3-A), the compiler emits them, and the kernel generates and switches keys. Missing any one leaves the protection off.
- No ATT&CK mapping in D3FEND. D3-PAN authenticates the Pointer artefact, which no ATT&CK technique in D3FEND's data acts on; its value is against the memory corruption step inside exploitation techniques.
- It is probabilistic and bypassable. Signing gadgets, pointer substitution and speculative guessing (the PACMAN research on Apple M1) have all been shown; it raises cost, it does not fix memory bugs.
- Verify the binary, not the build script. Check that shipped binaries actually contain the signing instructions and that the running kernel advertises the feature.
D3-PAN at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-PAN (d3f:PointerAuthentication) |
| Tactic | Harden |
| Parent technique | Application Hardening (D3-AH) |
| Siblings | Application Configuration Hardening, Control Flow Integrity, Dead Code Elimination, Exception Handler Pointer Validation, Process Segment Execution Prevention, Segment Address Offset Randomization, Stack Frame Canary Validation |
| Digital artefact | Pointer (relation: authenticates Pointer) |
| ATT&CK mapping | None in D3FEND data (checked November 2026, D3FEND 1.6.0) |
| Reference implementation named by D3FEND | Armv8.3-A Pointer Authentication; QARMA-64 as the architecture's specified algorithm, which implementations need not use |
| D3FEND references | Qualcomm, "Pointer Authentication on ARMv8.3"; Google Project Zero, "Examining Pointer Authentication on the iPhone XS" |
How it works
D3FEND's article describes the Arm design. A 64-bit pointer has more bits than the virtual address space needs, so the spare high bits hold the PAC. The PAC is computed over the pointer value and a 64-bit context value. Three groups of instructions handle it, as Project Zero's analysis lays out:
- Sign (PAC* instructions): compute the code and insert it into the pointer, for example when a function saves its return address.
- Authenticate (AUT* instructions): check the code and strip it if valid; if the check fails the pointer is corrupted so that using it faults. Combined forms authenticate and then branch, load or return in one instruction.
- Strip (XPAC* instructions): remove the code without checking, for debuggers and code that only needs the address.
There are five 128-bit keys: IA and IB for instruction pointers, DA and DB for data pointers, and GA for generic signing of larger data. The context value, which compilers call a discriminator, ties a signature to where or how the pointer is used, so that a valid signed pointer cannot simply be copied into a different slot. Clang's documentation describes address diversity, which binds a pointer to its storage address, and constant diversity, which uses a fixed per-declaration or per-type value.
D3FEND's considerations add two points that matter in practice: key management is left to the software (the kernel in practice), and signing gadgets can let an attacker sign arbitrary pointers.
ATT&CK relationships
D3FEND lists no ATT&CK technique for D3-PAN. Its artefact, Pointer, is not one that ATT&CK techniques are modelled as acting on, so D3FEND infers no relation. The table below is an NHI Mgmt Group view, not a D3FEND mapping: these ATT&CK v20 techniques commonly rely on memory corruption that redirects control flow, the step pointer authentication makes harder.
| ATT&CK ID | Technique | Where PAC raises cost (our view) |
|---|---|---|
| T1203 | Exploitation for Client Execution | Browser and document reader exploits that overwrite return addresses or function pointers |
| T1068 | Exploitation for Privilege Escalation | Kernel exploits that hijack kernel function pointers or returns, where the kernel is built with PAC |
| T1210 | Exploitation of Remote Services | Remote memory corruption in network services running on Arm servers |
| T1190 | Exploit Public-Facing Application | The same, for internet-facing applications on Arm hosts |
Logic flaws, injection and authentication bypasses in these techniques are untouched by PAC. The mitigation view is in M1050 Exploit Protection, and the bug classes are described in the Memory Corruption Vulnerabilities Guide.
Where it is implemented
| Layer | Feature or setting | What it does |
|---|---|---|
| Processor | Arm Pointer Authentication, introduced in Armv8.3-A | Provides the PAC, AUT and XPAC instructions and the five key registers |
| GCC and Clang (AArch64) | -mbranch-protection=pac-ret (sign return addresses with the A key), pac-ret+leaf (include leaf functions), pac-ret+b-key (use the B key), standard (all branch protection features); -msign-return-address is deprecated in favour of -mbranch-protection. The default in GCC is none | Return address signing for ordinary Linux and Android style builds |
| Clang arm64e ABI | Signs C function pointers, return addresses and v-table pointers on certain Apple operating systems; <ptrauth.h> intrinsics and the __ptrauth qualifier for custom schemas | Broader pointer coverage than return addresses alone; Clang describes the ABI as not yet fully stable |
| Linux kernel (arm64) | CONFIG_ARM64_PTR_AUTH for user space, ARM64_PTR_AUTH_KERNEL for in-kernel return protection; HWCAP_PACA and HWCAP_PACG advertise support; prctl PR_PAC_RESET_KEYS reinitialises keys | Random keys per process at exec, shared by threads and kept across fork |
| Virtualisation (KVM) | Guest vCPUs need both the address and generic authentication flags at initialisation; otherwise the key registers are hidden and PAC instructions in the guest fault | Determines whether guests on Arm cloud hosts get the protection |
| Apple platforms | arm64e builds; the A12 analysis by Project Zero shows Apple applying PAC in user space and kernel with its own key handling | System and app code on Apple silicon |
Pointer authentication pairs naturally with Branch Target Identification (bti in -mbranch-protection), which restricts where indirect branches may land; the GCC option standard turns on both. Related software checks are covered in D3-PV Pointer Validation and D3-SFCV Stack Frame Canary Validation.
Implementation steps
- Inventory Arm targets. List the 64-bit Arm platforms you build for: Arm servers and cloud instances, Android and Linux devices, Apple platforms, embedded boards. Record whether each processor implements Armv8.3-A pointer authentication.
- Turn it on in the toolchain. Add -mbranch-protection=standard (or pac-ret if BTI is not yet wanted) to release builds, including third-party libraries you compile. For Apple targets, follow the platform's arm64e guidance.
- Enable kernel support. Confirm the kernel is built with CONFIG_ARM64_PTR_AUTH and, for kernel self-protection, ARM64_PTR_AUTH_KERNEL; for virtual machines, confirm the hypervisor exposes the feature to guests.
- Test in a pilot ring. Run the full test suite on PAC-capable hardware. Hand-written assembly, JIT compilers, unwinders, crash reporters and code that stores raw pointers in unusual places are the usual sources of failures.
- Roll out and keep fallbacks. Code built with the hint-space instructions runs on processors without the feature, so one binary can serve mixed fleets. Rollback is a rebuild without the flag.
How to verify it works
- Feature check on the host: on Linux, confirm the kernel reports HWCAP_PACA and HWCAP_PACG (visible as the paca and pacg flags in the CPU features list).
- Binary check: disassemble a sample of release binaries and confirm function prologues and epilogues contain signing and authenticating instructions. Add this as a release gate so a build change cannot silently drop the flag.
- Fault test: in a test build, deliberately corrupt a signed return address in a harness and confirm the process faults rather than continuing. This proves the whole chain: hardware, compiler and kernel keys.
- Crash telemetry: after rollout, watch for authentication failures in crash reports; a cluster on one code path is either a bug or an exploitation attempt and deserves triage.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) |
|---|---|
| Release binaries for Arm64 built with branch protection | 100%, checked at release |
| Arm hosts and guests reporting pointer authentication support | All hosts whose processor supports it |
| Third-party native libraries built without branch protection | Tracked and falling |
| Pointer authentication crash reports triaged | All, within the normal crash triage window |
Limits and bypasses
- Signing gadgets and oracles: code that signs a pointer chosen by an attacker defeats the scheme. D3FEND lists this as the known limitation, Project Zero found a reachable gadget in the A12 kernel that Apple then patched, and Clang warns that unauthenticated signing and assignments to __ptrauth values can create signing oracles.
- Substitution: a valid signed pointer can be swapped for another with the same key and discriminator. Clang notes that the default arm64e C function pointer schema has no address diversity, which allows this.
- Short signatures: the PAC lives in spare bits, so its width depends on the address space configuration. Clang notes there may be substantially fewer bits than one might hope, and Project Zero estimated a roughly 24-bit PAC on the A12.
- Speculative guessing: the PACMAN research from MIT CSAIL (ISCA 2022) showed PAC guesses can be tested speculatively on Apple M1 without crashing, recovering valid codes; it still needs an existing memory corruption bug.
- Coverage gaps: return-address signing alone leaves data pointers and many function pointers unsigned, and code built without the flag is unprotected. Data-only attacks that never redirect control flow are outside its scope.
Moving code to memory-safe languages removes the bug class that PAC defends against; see the Memory-Safe Languages Guide.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-16 Memory Protection | Controls that protect memory from unauthorised code execution |
| NIST SP 800-53 Rev 5 | SA-15 Development Process, Standards, and Tools | Hardening compiler options as part of the build standard |
| NIST CSF 2.0 | PR.PS-06 | Secure software development practices integrated into the life cycle |
| MITRE ATT&CK | M1050 Exploit Protection | Mitigation family for exploit hardening |
| MITRE D3FEND | D3-AH, D3-PAN | Parent and technique |
Practitioner checklist
- List every Arm64 target and whether its processor implements pointer authentication.
- Build all release code, including vendored native libraries, with -mbranch-protection=standard or pac-ret.
- Confirm kernel and hypervisor support on servers, devices and cloud guests.
- Gate releases on a disassembly check for signing instructions.
- Run a fault test per platform to prove the protection triggers.
- Review custom code that signs pointers for signing oracles.
- Triage pointer authentication crashes as possible exploitation.
Standards and references
- MITRE D3FEND: Pointer Authentication (D3-PAN)
- Linux kernel documentation: Pointer authentication in AArch64 Linux
- GCC: AArch64 Options (-mbranch-protection)
- LLVM Clang: Pointer Authentication
- Google Project Zero: Examining Pointer Authentication on the iPhone XS
- MIT CSAIL: PACMAN, attacking Arm Pointer Authentication with speculative execution
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls (SI-16)
Related NHI Mgmt Group resources: Exploit Mitigations Guide · Memory Corruption Vulnerabilities Guide · M1050 Exploit Protection · MITRE D3FEND Guide