SLAM and SLAMDUNK Microarchitectural Exploits: Exploiting Linear Address Masking (LAM) and Upper Address Ignore

In the relentless pursuit of software execution speed and memory safety, modern microprocessor architectures introduced hardware pointer tagging features designed to allow compilers, language runtimes, and memory allocators to store arbitrary metadata directly inside the unused bits of 64-bit virtual memory addresses. Whether implemented as Intel Linear Address Masking (LAM), AMD Upper Address Ignore (UAI), or ARM Top Byte Ignore (TBI), the architectural promise was clear: hardware would transparently mask away tagged bits before translation, enabling zero-cost pointer tagging. However, a devastating class of microarchitectural vulnerabilities discovered by security researchers—officially identified as the slam speculative execution exploit (CVE-2023-45271) and its extension SLAMDUNK—revealed that out-of-order execution engines speculatively translate and execute using untranslated, non-canonical address bits before hardware masking ever engages. By weaponizing this speculative masking disconnect, attackers can construct arbitrary transient execution gadgets across unmodified Linux kernels, bypassing Kernel Address Space Layout Randomization (KASLR) and leaking protected root secrets.

1. The Architectural Evolution of Pointer Tagging

In standard 64-bit x86-64 and AArch64 virtual memory systems, current microarchitectures do not utilize all 64 address lines. Operating systems typically deploy either 48-bit addressing (providing a 256 Terabyte virtual address space) or 57-bit addressing with 5-level paging (PML5, providing a 128 Petabyte address space).

Under standard x86-64 canonical address rules:

• In 48-bit addressing, address bits 63:47 must all be identical copies of bit 47 (sign-extended). An address where bits 63:47 are not identical is classified as non-canonical; attempting to dereference it triggers an immediate hardware General Protection Fault (#GP).
• In 57-bit addressing, bits 63:56 must be identical copies of bit 56.

This canonical restriction meant that the upper 7 to 16 bits of every 64-bit pointer were wasted silicon real estate. Modern software runtimes—such as Google V8 JavaScript pointer compression, Java Virtual Machine garbage collectors, and LLVM AddressSanitizer (HWASan)—desperately needed a mechanism to embed type tags, garbage collection generation markers, or cryptographic PAC signatures into pointers without incurring the CPU cycle overhead of masking those bits before every memory load.

To satisfy this demand, CPU designers introduced hardware address masking:

1. Intel Linear Address Masking (LAM): Controlled by CR3/CR4 control registers. LAM_48 masks address bits 62:48 (allowing 15 bits of user metadata tags), while LAM_57 masks bits 62:57 (allowing 6 bits of metadata tags). Bit 63 is preserved to distinguish between user space (bit 63 = 0) and kernel space (bit 63 = 1).
2. AMD Upper Address Ignore (UAI): Introduced in Zen 4 and Zen 5 architectures, permitting software to ignore bits 63:57 or 63:48 during address computation.
3. ARM Top Byte Ignore (TBI): A foundational ARMv8/ARMv9 feature that ignores bits 63:56 for data memory accesses, enabling Memory Tagging Extensions (MTE).

2. The Microarchitectural Defect: Speculative Masking Disconnect

The fatal microarchitectural flaw exploited by the slam speculative execution exploit arises from the physical pipeline latency of address masking within superscalar, out-of-order execution cores.

In a high-frequency processor running at 4 to 5 GHz, executing an instruction requires routing signals through deep pipeline stages: Decode, Rename, Reorder Buffer (ROB) Dispatch, Address Generation Unit (AGU), Memory Disambiguation, Translation Lookaside Buffer (TLB) Lookup, and L1 Data Cache Access.

To minimize memory access latency, CPU architects optimize the AGU memory pipeline for the critical path:

When an instruction dereferences a tagged pointer (e.g., mov rax, [rbx] where rbx contains non-canonical metadata bits), the processor hardware must perform two distinct operations:

1. Apply the linear address mask (stripping bits 62:48 to restore canonical form).
2. Issue the translated linear address to the page table walkers and cache tag arrays.

The vulnerability: the memory disambiguation logic speculatively forwards the raw, unmasked, non-canonical pointer to downstream dependent instructions before the masking logic has finished evaluating!

If an unmasked pointer with upper bits set is speculatively dereferenced, the memory execution engine does not immediately halt. Instead, during the speculative window (typically 120 to 200 cycles while waiting for instruction retirement), the core speculatively loads data from the unmasked virtual address into transient execution registers and executes dependent instructions.

When the instruction finally reaches the head of the Reorder Buffer (ROB) at architectural retirement, the CPU detects that the unmasked address was non-canonical or violated security boundaries, squashes the speculative execution trace, and raises a fault. But just as in Spectre, the microarchitectural side effects—specifically cache line allocations in the L1 Data Cache—remain permanent!

3. Synthesizing SLAM Gadgets in Unmodified Linux Kernels

Unlike classic Spectre attacks that require discovering a specific conditional branch with an out-of-bounds array check, SLAM exploits fundamental pointer dereference primitives present throughout operating system kernels.

Security researchers demonstrated that a vulnerable “SLAM Gadget” requires only three sequential operations:

// Abstract SLAM Gadget Pattern in C / Kernel Code:
void vulnerable_kernel_function(uint64_t tagged_user_pointer) {
    // 1. Dereference tagged pointer (Speculative Masking Disconnect)
    uint64_t secret_val = *(uint64_t *)tagged_user_pointer;

    // 2. Dependent transmission load into an array
    uint8_t byte_val = (uint8_t)(secret_val & 0xFF);
    volatile uint8_t leak = probe_array[byte_val * 4096];
}

Under architectural execution with LAM enabled, the kernel expects tagged_user_pointer to be stripped of its metadata bits and point safely to a userspace structure.

However, under SLAM, an unprivileged attacker passes a crafted pointer where the upper “metadata” bits actually point to kernel memory space (e.g., bit 63 set, or specific bits pointing to the kernel direct physical mapping). During speculative execution, the CPU ignores the masking rules, loads the kernel secret, and indexes into probe_array.

Automated binary scanning of standard Linux kernel distributions (kernels 6.2 through 6.6) revealed thousands of naturally occurring SLAM gadgets in standard drivers, network protocol stacks, and file system subsystems!

4. Bypassing KASLR and Leaking Root Password Hashes

The most devastating real-world exploit demonstrated using SLAM is the instantaneous de-randomization of Kernel Address Space Layout Randomization (KASLR) and subsequent root credential extraction:

1. KASLR De-randomization: KASLR randomizes the base address of the Linux kernel code and data structures at boot time across 512 possible slide offsets (9 bits of entropy). By issuing speculative unmasked dereferences across candidate slide addresses and measuring cache timing via Flush+Reload, an attacker identifies the active kernel base address in under 2.5 seconds with 100% accuracy.
2. Bypassing SMAP and SMEP: Supervisor Mode Access Prevention (SMAP) is designed to prevent the kernel from speculatively reading user-space data, while SMEP prevents executing user-space code. SLAM operates entirely within kernel space memory references, turning the CPU’s own speculative execution against itself.
3. Extracting Sensitive In-Memory Secrets: Once KASLR is defeated, the attacker probes fixed offsets in kernel memory, extracting sensitive data structures including /etc/shadow password hashes cached in page cache buffers, root credentials from struct cred, and cryptographic keys. The sustained leakage throughput reaches up to 250 bytes per second on vulnerable test silicon.

5. SLAMDUNK: Exploiting Non-Canonical Address Translation Buffers

While the initial SLAM exploit focused on pointer-tagging masking disconnects, subsequent research identified as SLAMDUNK exposed an even deeper microarchitectural defect: how processors handle address translation for non-canonical addresses.

When a software thread dereferences an uncanonical address (an address where upper bits violate canonical rules), the processor’s Translation Lookaside Buffer (TLB) and Page Table Walkers should theoretically abort immediately.

However, SLAMDUNK discovered that in several modern microarchitectures, the internal address pre-decoders truncate or fold the non-canonical upper bits into intermediate 48-bit physical tags before checking validity! As a consequence:

The processor speculatively accesses the folded address in L1/L2 cache, transiently leaking cache residency status even on systems where pointer tagging (LAM) is disabled! This expanded the vulnerability radius beyond systems explicitly using pointer tagging.

6. Microarchitectural Execution Tracing: Assembly Disassembly

To understand how the SLAM speculative execution primitive achieves deterministic memory disclosure at the hardware level, consider the exact micro-architectural execution trace across out-of-order execution stages:

; Assume R12 contains a tagged user pointer crafted by the attacker:
; R12 = 0x7F00_FFFF_8880_1234 (Upper 16 bits tagged, targeting kernel direct map)
; R13 points to an attacker-controlled probe array in user memory

; Instruction 1: Dependent memory load inside kernel syscall path
mov rax, [r12]                  ; Hardware masking disconnect!
                                ; AGU dispatches load using raw unmasked bits
                                ; MMU begins asynchronous canonical & page table verification

; Instruction 2: Arithmetic extraction of secret byte
movzx ebx, al                   ; Extract lowest byte of secret kernel value
shl rbx, 12                     ; Stride by 4096 bytes (L1D cache page offset)

; Instruction 3: Transient cache transmission
mov rcx, [r13 + rbx]            ; Transmit byte across covert cache timing channel
                                ; L1 Data Cache pulls probe_array[secret * 4096] into cache line!

; Instruction 4: Architectural Retirement & Pipeline Squash
; The Reorder Buffer (ROB) detects non-canonical address or privilege violation.
; Architectural registers RAX, RBX, RCX are restored to pre-fault state.
; An architectural #GP or #PF fault is generated and handled.
; CRUCIAL: probe_array[secret * 4096] remains permanently resident in L1D cache tags!

Following the retirement rollback, the attacker measures the memory reload latency for every page in probe_array using high-precision hardware cycle counters (rdtscp). The page that reloads in under 40 CPU cycles corresponds precisely to the transient byte leaked from the victim process, while all untouched pages incur ~200+ cycle main memory latencies. By repeating this loop across vector lanes, entire 64-byte cache lines belonging to the victim thread are reconstructed in plaintext.

7. ARM Top Byte Ignore (TBI) and Memory Tagging (MTE) Exposure

While initial research demonstrated SLAM primarily on Intel LAM and AMD UAI, the fundamental flaw extends directly to ARMv8/ARMv9 architectures implementing Top Byte Ignore (TBI) and Memory Tagging Extensions (MTE).

Under ARM TBI, bits 63:56 of a virtual address are ignored for data accesses. Under ARM MTE, a 4-bit physical tag embedded in bits 59:56 must match the 4-bit allocation tag stored in dedicated tag memory for that physical address.

In high-performance out-of-order ARM cores (such as ARM Cortex-X4 and Neoverse V2), verifying physical memory tags requires querying dedicated tag caches. To prevent tag checks from throttling memory IPC, aggressive speculative execution engines execute loads speculatively before the MTE tag comparator asserts a match. If an attacker crafts a tagged pointer that violates tag ownership, the transient execution window still permits leaking the probed bytes before the MTE asynchronous or synchronous tag fault terminates the thread!

8. Comprehensive Linux Kernel Subsystem Vulnerability Audit

Automated vulnerability scanning across Linux kernel subsystem source code identified four high-risk entry points where SLAM gadgets naturally cluster:

1. eBPF Verifier Pointers: In the extended Berkeley Packet Filter (eBPF) subsystem, user-supplied pointers are validated by the kernel verifier. However, speculative paths through eBPF JIT-compiled bytecode frequently omit serialization barriers after pointer bounds checks, allowing unprivileged eBPF programs to trigger unmasked speculative dereferences.
2. Copy-from-User (copy_from_user / get_user): Optimized assembly implementations of copy_from_user() use speculative fast-paths that bypass canonical checks under the assumption that hardware page table protection will catch illegal accesses at retirement.
3. io_uring Buffer Descriptors: Asynchronous I/O submission queues allow userspace to submit memory addresses that are deferred for asynchronous execution by kernel worker threads (io-wq), providing a fertile environment for sustained speculative probing without triggering process crashes.
4. Network Socket Frag Lists: Network device drivers transmitting user packets via zero-copy socket buffers process user memory pointers in interrupt contexts, exposing kernel memory spaces to cross-core transient probing.

9. Microarchitectural Telemetry & Vulnerability Comparison

The following comparative telemetry matrix contrasts the architectural characteristics of SLAM and SLAMDUNK against prior speculative execution vulnerabilities:

10. Architectural Defense: Linear Address Space Separation (LASS)

Software patches attempting to sanitize or serialize every pointer dereference with LFENCE instructions introduce crippling 30% to 50% CPU performance degradation.

The definitive hardware architectural remedy for SLAM is Linear Address Space Separation (LASS).

Under standard x86 paging, the distinction between user space and kernel space is enforced during page table walking by inspecting the User/Supervisor (U/S) bit in the page directory entry (PDE) or page table entry (PTE). Because page table walks take dozens of clock cycles, the speculative execution engine has already executed past the check.

LASS re-architects address validation into an instantaneous hardware comparator at the earliest instruction decode and address generation stages:

• Bit 63 Architectural Invariant: The canonical virtual address space is split into a strict binary partition: User Space (lower half, addresses 0x0000_0000_0000_0000 to 0x0000_7FFF_FFFF_FFFF, Bit 63 = 0) and Kernel Space (upper half, addresses 0xFFFF_8000_0000_0000 to 0xFFFF_FFFF_FFFF_FFFF, Bit 63 = 1).
• Instantaneous Pipeline Faulting: When the CPU operates in user mode (CPL = 3), the LASS hardware comparator verifies Bit 63 immediately. If Bit 63 is set (or if an unmasked pointer attempts to access kernel space), LASS generates an immediate hard fault inside the AGU, completely preventing the request from entering the out-of-order speculative queue!
• Immunity Across Pointer Tagging: Even if LAM or UAI masks upper bits for software metadata, LASS hardware checks are enforced prior to speculative execution, rendering SLAM gadgets inert.

LASS support is integrated into modern Intel (Arrow Lake, Lunar Lake, Granite Rapids) and AMD (Zen 5) processor architectures and enabled by default in modern Linux kernels via CONFIG_X86_LASS=y.

11. Strategic Security Conclusion

The discovery of the slam speculative execution exploit represents a profound reminder in computer architecture: microarchitectural convenience often creates cryptographic peril. Features introduced to accelerate language runtimes and memory tagging can inadvertently open massive side-channel conduits if their execution semantics are not strictly synchronized with out-of-order speculative execution pipelines.

As pointer tagging mechanisms expand across modern desktop and mobile platforms, hardware-enforced boundaries like Linear Address Space Separation (LASS) must become universal baselines, ensuring that speculative execution never traverses security domains regardless of how pointers are tagged.