SLAM Under the Hood: How Hardware Pointer Tagging (LAM/UAC/TBI) Reopens Spectre Speculative Exploits

In modern operating system architectures, the 64-bit virtual memory address space is vastly underutilized. Even with the introduction of 5-level paging (PML5) scaling addressable memory to an astronomical 128 petabytes, standard user processes consume only 48 or 57 bits of linear address space. For years, software runtimes, memory-safe allocators, garbage collectors, and security sanitizers (such as AddressSanitizer and Java JVMs) dreamed of repurposing the unused upper 7 to 16 bits of a 64-bit pointer to store metadata tags, object lifetimes, and memory ownership capabilities. To answer this demand without incurring expensive bit-masking instruction overhead, processor manufacturers introduced hardware-level pointer tagging: Intel Linear Address Masking (LAM), AMD Upper Address Ignore (UAI/UAC), and Arm Top-Byte-Ignore (TBI).

However, hardware optimizations that alter address translation pipelines invariably open microscopic cracks in microarchitectural security. Tracked under CVE-2024-28854, security researchers at VUSec uncovered SLAM (Speculative Linear Address Masking)—a devastating transient execution attack that demonstrates how hardware pointer tagging enables attackers to bypass canonical virtual address checks, weaponize Spectre-style speculative gadgets, and leak arbitrary kernel memory at speeds reaching 1.2 KB/s across modern CPU architectures. Here is an exhaustive technical audit of how hardware pointer tagging works, how SLAM breaks microarchitectural isolation, and how the Linux kernel is forced to patch this vulnerability.

1. The Anatomy of Canonical Virtual Memory vs. Hardware Pointer Tagging

To understand how SLAM achieves speculative arbitrary code execution, one must examine the foundational rules of x86-64 virtual memory. In standard 64-bit computing, the architecture enforces a strict concept known as Canonical Address Form.

Under standard 48-bit 4-level paging, virtual addresses use only bits [47:0]. To prevent ambiguous address representations and simplify future hardware scaling, the x86 architecture mandates that bits [63:48] must be a direct sign-extension of bit 47:

• For user-space memory (where bit 47 is 0), bits [63:48] must be all zeros: 0x0000_0000_0000_0000 to 0x0000_7FFF_FFFF_FFFF.
• For kernel-space memory (where bit 47 is 1), bits [63:48] must be all ones: 0xFFFF_8000_0000_0000 to 0xFFFF_FFFF_FFFF_FFFF.

If any software instruction attempts to dereference a non-canonical address—for example, an address where bit 63 is set to 1 while accessing user memory (e.g., 0x8000_1234_5678_0000)—the CPU’s Memory Management Unit (MMU) instantly aborts the execution and raises a fatal General Protection Fault (#GP) before any bus transaction or page table walk is initiated.

For decades, this canonical check guaranteed that software could not arbitrarily embed metadata into pointer bits without explicitly executing bitwise masking instructions (e.g., AND rax, 0x0000FFFFFFFFFFFF) prior to every single memory load or store.

To eliminate this masking overhead, chipmakers introduced hardware-level pointer tagging:

1. Intel Linear Address Masking (LAM): Controlled via control register CR3 (bits 61 and 62) and CR4, LAM provides two configurations: LAM-57 (masks bits [62:57], providing 6 metadata bits) and LAM-48 (masks bits [62:48], providing 15 metadata bits). Crucially, the hardware memory interface strips these metadata tag bits during address translation, treating the pointer as canonical.
2. AMD Upper Address Ignore (UAI): Introduced in Zen 4 architectures, UAI allows user-space pointers to store arbitrary tag bytes in bits [63:57], stripping them automatically before page table walks.
3. Arm Top-Byte-Ignore (TBI): Long implemented in Armv8-A and Apple Silicon, TBI ignores bits [63:56] in data memory accesses, enabling technologies like Android’s Scudo memory allocator and Hardware-assisted AddressSanitizer (HWASan).

2. The Microarchitectural Flaw: Speculative Non-Canonical Dereferencing

The fatal assumption behind hardware pointer tagging was that hardware masking is completely transparent to software security boundaries. Security architects assumed that because the hardware strips tag bits before accessing the cache and translation lookaside buffer (TLB), tagged pointers would behave identically to untagged pointers.

The researchers behind SLAM uncovered that this assumption completely breaks down under out-of-order speculative execution.

In modern superscalar processors, the execution pipeline is decoupled into front-end branch prediction, out-of-order execution units, and an in-order retirement unit (Reorder Buffer, ROB). When a program encounters a conditional branch (such as a pointer bounds check or a syscall validation routine), the branch predictor makes a speculative guess and immediately dispatches subsequent instructions down the predicted path.

Crucially, hardware address masking logic in existing silicon implementations operates as an asynchronous transformation in the Address Generation Unit (AGU). During speculative execution:

• The processor receives a non-canonical, tagged address supplied by an unprivileged attacker.
• While the architectural commit stage will eventually verify canonical validity or enforce user/kernel isolation, the speculative execution pipeline begins memory operations immediately.
• On processors with LAM enabled, the CPU speculatively masks the address, treating non-canonical pointers as valid, and issues transient speculative loads to L1/L2 caches.
• Even more alarmingly, the researchers discovered that on certain Intel and AMD CPUs, speculative execution will dereference non-canonical addresses even when LAM is disabled! Because canonical address checking logic is evaluated late in the pipeline (at retirement or fault delivery), the out-of-order core transiently accesses memory locations that software never authorized.

3. Constructing the SLAM Exploit Primitive: Spectre-BTI and Transient Gadgets

To transform this speculative non-canonical dereference into an end-to-end kernel exploit, an attacker combines SLAM with Spectre-BTI (Branch Target Injection, CVE-2017-5715) or Spectre-v2.

Consider a standard Linux kernel code path containing an indirect function call or a speculative dereference gadget:

Under standard x86 execution rules without pointer tagging, if an attacker in user-space passes a pointer residing in kernel address space (e.g., 0xFFFF_8880_0000_1000) or an invalid non-canonical address, the kernel’s access-validation checks (such as access_ok() or hardware SMAP/SMEP) would intercept it.

However, under SLAM with pointer tagging enabled:

1. Tag Obfuscation: The attacker passes a tagged pointer containing arbitrary metadata in the upper bits (e.g., 0x4200_FFFF_8880_1000). To software sanitization checks that do not strip tags, this address looks like an arbitrary user buffer.
2. Branch Target Poisoning: The attacker trains the Branch Target Buffer (BTB) to mispredict the indirect branch toward the vulnerable dereference gadget.
3. Transient Canonical Dereference: During the misprediction window (typically 150 to 250 clock cycles while the CPU resolves branch mispredictions), the AGU strips the tag, producing a valid target address. The speculative load executes, reading a sensitive byte (e.g., an encryption key, root password hash, or kernel ASLR base) into a CPU register.
4. Cache Transmission: The second instruction in the gadget uses the secret byte as an index into an attacker-accessible array (shared_array[secret_byte * 4096]), pulling that specific 4KB cache line into the L1/L2 data cache.
5. Fault Suppression and Flush+Reload: When the branch misprediction is finally detected, the pipeline flushes the instructions and suppresses any hardware faults. However, the state of the cache remains altered! The attacker probes the shared_array using high-precision timers (RDTSC); the cache line that loads in ~30 cycles reveals the secret kernel byte.

4. Microarchitectural Attack Surface: Branch Predictor Training & KASLR Bypass

To achieve reliable data exfiltration without crashing the system, the SLAM attack orchestrates a sophisticated multi-stage synchronization pipeline between user-space and kernel-space:

Phase A: Branch History Table (BHT) & BTB Collisions: Modern superscalar cores utilize sophisticated branch predictors such as TAGE-SC-L (Tagged Geometric History with Statistical Correlator and Loop Predictor). Because the BTB uses truncated virtual address hashes to index target destinations, an unprivileged user process can map memory at an address that aliases with the kernel gadget’s virtual address hash. By repeatedly executing an indirect jump to a valid target in user-space, the attacker primes the BTB. When a syscall enters the kernel, the hardware branch predictor transiently jumps straight to the victim speculative gadget before the privilege change is reconciled.

Phase B: Defeating Kernel ASLR (KASLR): Modern Linux kernels randomize their base virtual address in memory upon every boot (Kernel Address Space Layout Randomization). Without knowing the KASLR offset, an attacker cannot target specific kernel variables. SLAM defeats KASLR in less than 200 milliseconds by performing a speculative sweep across possible 2MB kernel text alignment boundaries. When the speculative tagged pointer strikes a mapped kernel page, the transient cache fill generates a distinct cache reload hit, whereas an unmapped page incurs a TLB miss penalty. Once the KASLR slide is discovered, targeted secret exfiltration begins.

Phase C: Exfiltrating the Root Shadow File and Cryptographic Keys: By incrementing the tagged target pointer byte-by-byte (traversing kernel structures like init_cred, task_struct, and the page cache), SLAM streams memory contents across the microarchitectural covert channel. In controlled laboratory conditions on Intel Lunar Lake and AMD Zen 4 hardware, researchers achieved sustainable exfiltration bandwidths exceeding 1,200 bytes per second, sufficient to capture root cryptographic tokens and SSL master secrets in seconds.

5. Hardware Pointer Tagging Implementations and Vulnerability Matrix

The following technical comparison highlights how different processor architectures implement hardware pointer tagging and their respective vulnerabilities to speculative linear address masking:

6. Operating System Mitigations: Linux Kernel LASS and Software Hardening

When the VUSec disclosure landed, the Linux kernel community was faced with a critical engineering dilemma: hardware pointer tagging was actively being prepared for enterprise deployment in Linux 6.4 and 6.5 kernels to supercharge memory-safety tooling, but enabling it exposed systems to root-level data leakage.

The Linux kernel security team responded with a multi-layered defense strategy:

• Disabling Intel LAM by Default: Linux maintainers immediately blocked the default enablement of LAM in user-space processes until strict microarchitectural boundaries could be guaranteed.
• Hardware Linear Address Space Separation (LASS): The definitive hardware fix on next-generation Intel silicon (Arrow Lake, Lunar Lake, Sierra Forest) is LASS. Controlled via CR4 (bit 27), LASS enforces an immediate architectural and speculative boundary: any user-mode access (CPL=3) attempting to touch an address with bit 56/63 set (kernel space) is blocked at the hardware decode stage, completely neutralizing speculative dereferences before AGU translation.
• Speculative Barriers (LFENCE Insertion): In existing processors lacking LASS, compilers and kernel entry points must insert serialization barriers (LFENCE) before sensitive pointer dereferences in syscall entry vectors. Because LFENCE forces the processor to drain all previous instructions and resolve branches before proceeding, speculative non-canonical execution windows are completely closed.

Frequently Asked Questions About SLAM and Hardware Pointer Tagging