Overview

An address space conflict arises when different instruction sequences—or different artifacts produced by an analysis tool—must occupy the same memory addresses, but their contents, semantics, or side effects are incompatible. The conflict prevents the affected sequences from being linearly arranged in memory and from being executed without mutual interference. The concept has been articulated in two independent research contexts:

1. Processor fuzzing for transient execution bugs (DejaVuzz, ASPLOS '25), where a fuzzer must place both microarchitectural-training instructions and transient-window instructions in a single shared memory image.
2. Dynamic binary analysis / taint tracking (HALF, arXiv 2512.22043), where in-process instrumentation pollutes the target's native memory layout.

Manifestation in Processor Fuzzing

In processor fuzzers that generate transient execution gadgets, the fuzzer must arrange two kinds of instruction sequences in the same flat address space:

• Training sequences that steer branch predictors, predictors of other microarchitectural structures, or other predictors into a desired state.
• Transient-window sequences that, once mispredicted, speculatively access secret data and encode it into microarchitectural state.

Because the fuzzer cannot predict in advance which training instructions will be effective or precisely where transient windows must be located, it is difficult to lay the two kinds of sequences out linearly without collision. As described in the DejaVuzz paper:

"The root cause of the above challenges is the address space conflict. Since the fuzzer cannot predict training effectiveness or transient window locations, instructions are hardly placed at the desired address. For example, training instructions may occupy addresses needed for transient windows, and different training instructions cannot be tested at the same address."

Three Concrete Conflict Patterns

DejaVuzz enumerates three categories of conflicts observed when generating training and transient sequences for an out-of-order core such as BOOM:

These conflicts make it impractical for existing fuzzers to arrange the instructions linearly. As a consequence, prior template-based fuzzers (e.g., IntroSpectre, TEESec) only cover a small set of window templates, while random-based fuzzers (e.g., SpecDoctor) must discard transient windows containing backward jumps because such windows cannot survive the necessary substitutions.

Manifestation in Dynamic Binary Analysis

In the HALF framework paper, "address-space conflict" is used to describe a different but structurally analogous problem in binary program analysis. Traditional in-process dynamic taint analysis tools insert instrumentation directly into the target process. The instrumentation code, shadow memory, and other analysis artifacts compete for the same virtual address ranges as the program's native code and data, altering the memory layout that an exploit or evasive malware sample was originally compiled or packed against.

"Traditional in-process analysis tools trigger severe address-space conflicts that inevitably disrupt the native memory layout of the target. These conflicts frequently cause layout-sensitive exploits and evasive malware to deviate from their intended execution paths or fail entirely."

The practical consequence is a loss of analysis fidelity: layout-sensitive exploits—whose success depends on hard-coded gadget addresses, ROP chain offsets, or precise memory distances—no longer reproduce under the instrumented binary. HALF addresses this by using kernel-assisted process hollowing to give the analysis tool an address-space-transparent observation point, eliminating the layout-disruption artifact.

Resolution via Dynamic Swappable Memory

In the processor-fuzzing context, address space conflicts are resolved by the Dynamic Swappable Memory (swapMem) operating primitive introduced by DejaVuzz. Instead of placing all sequences in a single static linear layout, swapMem defines a swappable region of the address space whose contents can be replaced at runtime. The fuzzer stages different instruction sequences (e.g., predictor-training sequence (1) or (2), followed by transient sequence (3)) and swaps them in and out as needed. After swapping a new sequence into the swappable region, the design-under-test jumps to its entry and continues execution. This time-multiplexes the address space among different semantics and:

• Frees the full address space for training sequences, allowing training branches to be placed at the exact addresses the transient sequence will later jump to (avoiding W1-type conflicts).
• Removes training instructions from the transient sequence's view entirely (avoiding W1- and W3-type conflicts).
• Allows conflicted register assignments to be relocated to other available addresses, such as 0x0, to resolve W2-type conflicts.
• Enables exploration of multiple training effects by trying different combinations (e.g., (1)(3) vs. (2)(3)) to identify which training sequence actually contributes to triggering the transient window.

The primitive is described as acting as an isolation primitive that enhances microarchitectural controllability, with the explicit claim that "the swapMem enhances microarchitectural controllability as the isolation primitive, resolving address space conflicts."

Significance

Address space conflict is therefore a unifying structural problem that arises whenever a tool must simultaneously (a) produce or preserve specific memory contents at specific addresses and (b) observe or influence execution from inside the same address space. In fuzzing, it constrains the diversity of transient windows a fuzzer can generate; in binary analysis, it limits which exploits and evasive samples can be reproduced under instrumentation. The two domains have proposed analogous mitigations—time-sharing the address space (DejaVuzz's swapMem) or relocating the analyzer out of the target's address space (HALF's kernel-assisted hollowing)—both of which decouple the analyzer's memory footprint from the target's layout.