SOL-2026-7: Memory Is Fun Until the Optimizer Gets It Wrong

After working with JIT bugs in V8, I wondered whether solc's Yul optimizer could make a similar mistake. V8's optimizing compilers include Maglev and TurboFan, and I started looking for cases where an optimizer kept using an assumption after the value it described had changed. This bug was one result of that compiler hunt.

Solidity's Yul optimizer remembers values written to memory and storage. It uses that knowledge to replace later loads with known values and to remove stores that would not change anything. This bug arose when a Yul variable used to calculate an address was reassigned, but the optimizer kept an address relation based on its old value. A later load could then use an outdated value, or a necessary store could be removed.

The bug affects code compiled with the Yul optimizer enabled in Solidity 0.8.19 through 0.8.37. With --via-ir, any code may be affected. With the default evmasm pipeline, the affected code is limited to compiler-generated Yul utility functions and some inline assembly blocks.

I reported this to the Ethereum Foundation bug bounty program on August 17, 2026. The patch missed the next Solidity update, 0.8.37, released on September 10. That version still miscompiles the reproducer. The fix merged on October 14 and shipped with 0.8.38, alongside the Solidity team's security advisory on October 22. The bug tracker assigned it SOL-2026-7.

Two writes, one address

LoadResolver can replace mload(p) with a previously stored value when it knows that nothing has overwritten the 32 bytes at p. It must discard that knowledge when another store might address the same word. The equivalent rule applies to storage loads and stores.

In this Yul PoC, both addresses evaluate to 0x20:

first write:  a = v_before       = 0x20
second write: b = v_after + 0x20 = 0 + 0x20 = 0x20

The first write puts 0x20 there. The second puts 0 there, so mload(a) must return 0. The broken address bookkeeping instead compares a and b as if both were based on the same value of v. It sees v and v + 0x20 as nonoverlapping memory words. In reality, v changed between the two address calculations.

The Yul PoC

Here is the complete standalone Yul PoC:

1
{
2
    sstore(0, 0x20)
3
    sstore(1, 0)
4

5
    let v := sload(0)
6
    mstore(v, v)
7
    let a1 := v
8
    let a := a1
9
    mstore(a, a)
10

11
    v := sload(1)
12
    let b := add(v, 0x20)
13
    mstore(b, v)
14

15
    let result := mload(a)
16
    mstore(0, result)
17
    return(0, 0x20)
18
}

The first mstore(v, v) primes the optimizer's address cache before it sees mstore(a, a). The copies through a1 and a retain the old value 0x20 when v is later reassigned to zero. Removing that first memory store prevents the bad substitution in this small program. The storage round trip and isolated optimizer step preserve the shape needed to expose the stale relation.

I compiled it with the LoadResolver step alone:

solc --strict-assembly --optimize --yul-optimizations 'L:' --bin poc.yul

With 0.8.37, the optimized Yul changes let result := mload(a) into let result := a. That returns the old value, 0x20, even though the second store wrote zero to the same address. 0.8.38 keeps the load and returns 0. Here is the output from executing both L: builds as creation code on Anvil:

1
# solc 0.8.37
2
0x0000000000000000000000000000000000000000000000000000000000000020
3

4
# solc 0.8.38
5
0x0000000000000000000000000000000000000000000000000000000000000000

The first result is wrong, as one can see. The second matches the zero stored at address 0x20. With the default optimizer sequence, this particular Yul snippet also returns zero on 0.8.37. The Solidity example below reaches the bug with that sequence enabled.

The bytecode difference

This is the complete opcode diff between the two L: builds using the compilers' default EVM target. Both use PUSH0 to put zero on the stack:

1
--- solc 0.8.37
2
+++ solc 0.8.38
3
@@ -1,16 +1,16 @@
4
 00000000: PUSH1 0x20
5
 00000002: PUSH0
6
 00000003: DUP2
7
 00000004: DUP2
8
 00000005: SSTORE
9
 00000006: PUSH1 0x01
10
 00000008: DUP2
11
 00000009: SWAP1
12
 0000000a: SSTORE
13
 0000000b: DUP1
14
 0000000c: DUP3
15
 0000000d: MSTORE
16
-0000000e: DUP2
17
-0000000f: DUP2
18
+0000000e: DUP1
19
+0000000f: DUP1
20
 00000010: MSTORE
21
 00000011: RETURN

The shared SSTOREs set slots 0 and 1 to 0x20 and 0. The MSTORE at 0x0d writes zero at memory address 0x20, which is the second Yul memory write. At that point the remaining stack is [0, 0x20], with the top item shown first. In the 0.8.37 output, the first DUP2 copies 0x20 as the result, the second copies 0 as the destination for MSTORE. RETURN therefore emits 0x20. In 0.8.38, the two DUP1s supply zero as both the result and destination, so RETURN emits zero. The EVM instructions each do what they say. The wrong choice comes from 0.8.37 replacing mload(a) with its stale assumption that a still contains 0x20. The 0.8.38 optimized Yul retains mload(a), although final EVM code generation can reuse the zero on the stack instead of emitting an MLOAD opcode.

No assembly required

The Solidity PoC below uses a fixed-size array of structs, each occupying one storage slot. The first loop establishes i, then k = i + 2. It writes through a[k], increments i in a second loop, writes through a[i], and finally returns a[k].v:

1
// SPDX-License-Identifier: MIT
2
pragma solidity >=0.8.19 <0.9.0;
3

4
contract C {
5
    struct S { uint256 v; }
6
    S[20] public a;
7

8
    function g(uint256 max1, uint256 max2, uint256 aaaa, uint256 bbbb) external returns (uint256) {
9
        uint256 i;
10
        for (uint256 j; j < max1; j++) i++;
11
        uint256 k = i + 2;
12
        a[k].v = aaaa;
13
        for (uint256 j; j < max2; j++) i++;
14
        a[i].v = bbbb;
15
        return a[k].v;
16
    }
17
}

For g(0, 2, 0xaaaa, 0xbbbb), the first loop does not run, so i = 0 and k = 2. The first write sets a[2].v to 0xaaaa. The second loop increments i twice, and the second write sets that same slot to 0xbbbb. The final read must return 0xbbbb. Because the struct occupies exactly one slot and the static array begins at slot zero, array index 2 maps directly to storage slot 2.

1
[FAIL: returned stale first value] test_second_write_is_returned()
2
Logs:
3
actual return:
4
0x000000000000000000000000000000000000000000000000000000000000aaaa
5
stored a[2].v:
6
0x000000000000000000000000000000000000000000000000000000000000bbbb

1
[PASS] test_second_write_is_returned()
2
Logs:
3
actual return:
4
0x000000000000000000000000000000000000000000000000000000000000bbbb
5
stored a[2].v:
6
0x000000000000000000000000000000000000000000000000000000000000bbbb

The 0.8.37 run shows g returning 0xaaaa, while the generated public getter a(2) immediately reads 0xbbbb from storage. The first assertion confirms the second write happened, the second fails because the function's return value is stale. With 0.8.38, both the return value and storage getter are 0xbbbb.

Looking at the optimized Yul pins down the miscompilation. After the second sstore, 0.8.37 writes the first call argument straight into the return buffer:

sstore(var_i, calldataload(100))  // second write: bbbb
mstore(memPos, value_2)           // first value: aaaa

With 0.8.38, the return path actually reloads the original slot:

sstore(var_i, calldataload(100))
let current := sload(sum)        // sum is the slot for a[k]
mstore(memPos, current)

These snippets are reduced from the generated Yul, variable names and comments are adjusted for readability. Whether the bug fires depends on the intermediate code that reaches LoadResolver. Surrounding code, compiler version, and earlier optimizer steps can all change that code.

EqualStoreEliminator drops a required store

Another Yul optimizer step, EqualStoreEliminator, uses the same remembered contents as LoadResolver. It removes a write when the destination is already known to hold that value. The compiler's regression test shows the failure mode:

1
{
2
    let t := sload(0)
3
    if calldataload(64) { t := sload(5) }
4
    let a := t
5
    let c := add(a, 2)
6
    let v := calldataload(0)
7
    let w := calldataload(32)
8
    let old := sload(c)
9
    sstore(c, v)
10
    // The value of `t` is unknown both before and after this.
11
    if calldataload(96) { t := sload(6) }
12
    sstore(t, w)
13
    // `t` and `c` can be equal, so this cannot be removed.
14
    sstore(c, v)
15
}

I adapted it into a self-contained Yul variant that runs as creation code. At runtime, c and the new t both equal 0x102. The final store is necessary because the store through t changed the slot from 11 to 22. With only E enabled, 0.8.37 removes the final store and the creation call returns 22 (0x16). 0.8.38 keeps it and returns 11 (0x0b). The earlier sload(c) primes the address cache, removing it also stops this small reproducer from miscompiling.

A cached address outlives its base

When a store might overwrite a remembered value, DataFlowAnalyzer must discard that value. In its storage branch, vars->first is the new address and key is a tracked address:

70
boost::unordered::erase_if(m_state.environment.storage, mapTuple([&](auto&& key, auto&& value) {
71
    return
72
        !m_knowledgeBase.knownToBeDifferent(vars->first, key) &&
73
        vars->second != value;
74
}));

The memory branch makes the same check with knownToBeDifferentByAtLeast32: two 32-byte words are separate only when their starting addresses are at least 32 bytes apart. Both checks use KnowledgeBase::differenceIfKnownConstant, which compares each address as a base variable plus an offset:

49
std::optional<u256> KnowledgeBase::differenceIfKnownConstant(YulName _a, YulName _b)
50
{
51
    VariableOffset offA = explore(_a);
52
    VariableOffset offB = explore(_b);
53
    if (offA.reference == offB.reference)
54
        return offA.offset - offB.offset;
55
    else
56
        return std::nullopt;
57
}

In 0.8.37, a reassignment could leave a cached relation intact when the variable had no tracked expression before or after the change. In the Yul PoC, a keeps the old v = 0x20, while b uses the new v = 0 plus 0x20. Both addresses are 0x20, but the cache compares them as v and v + 0x20, keeps the old memory value, and replaces mload(a) with 0x20.

The Solidity PoC repeats the error in storage. The cached relation k = i_old + 2 survives the second loop. When i reaches 2, sstore(i, 0xbbbb) overwrites slot k, but the optimizer compares symbolic slots i and i + 2 and retains 0xaaaa for the final load. The compiler's loop regression test shows the same sequence:

1
{
2
    let i := 0
3
    for { let j := 0 } lt(j, calldataload(0)) { j := add(j, 1) } { i := add(i, 1) }
4
    // Only becomes a copy of `i` after the common subexpression eliminator, so `k` does not reference `i` directly.
5
    let i1 := add(i, 0)
6
    let k := add(i1, 2)
7
    sstore(k, add(sload(k), calldataload(64)))
8
    // The value of `i` is unknown both before and after this.
9
    for { let j := 0 } lt(j, calldataload(32)) { j := add(j, 1) } { i := add(i, 1) }
10
    sstore(i, calldataload(96))
11
    // `i` and `k` can be equal, so this cannot be resolved.
12
    mstore(0, sload(k))
13
    return(0, 32)
14
}

The offset-base regression test catches another lookup order: c is derived from the old t, then t changes. The later store through c may overwrite the value read through the new t:

1
{
2
    let t := calldataload(0)
3
    // Only becomes a copy of `t` after the common subexpression eliminator, so `c` does not reference `t` directly.
4
    let a := add(t, 0)
5
    let c := add(a, 2)
6
    let v := calldataload(64)
7
    let old := sload(c)
8
    sstore(c, v)
9
    // `c` still refers to the old value of `t`.
10
    t := calldataload(32)
11
    let x := sload(t)
12
    let w := calldataload(96)
13
    // `c` and `t` can be equal, so this store invalidates what is known about `sload(t)`.
14
    sstore(c, w)
15
    mstore(0, sload(t))
16
    return(0, 32)
17
}

The keccak regression test shows the same aliasing mistake affecting a hash instead of a load. After the second write, keccak256(a, 32) must hash the new contents:

7
    let v := sload(0)
8
    let a1 := add(v, 0x100)
9
    let a := add(a1, 0x10)
10
    let oldValue := 67
11
    mstore(a, oldValue)
12

13
    v := sload(1)
14
    let b := add(add(v, 0x200), 0x10)
15
    let newValue := 7
16
    mstore(b, newValue)
17

18
    // `a` and `b` can be equal, so this cannot be replaced by the hash of `oldValue`.
19
    let len := 32
20
    let hash := keccak256(a, len)
21
    sstore(0, hash)

How the patch fixes it

The fix explicitly marks changed variables in DataFlowAnalyzer::clearValues:

353
// Only the variables to clear changed. The values of the referencing variables did not
354
// change, we just forgot their expressions because we can no longer evaluate them.
355
// What the knowledge base computed for them is still valid though.
356
for (auto const& name: _variablesToClear)
357
    m_knowledgeBase.variableChanged(name);

KnowledgeBase::variableChanged increments that variable's version, and VersionedVariable holds its name and version:

88
/// Has to be called whenever the value of @a _var changes.
89
void variableChanged(YulName const _var)
90
{
91
    yulAssert(!m_valuesAreSSA);
92
    yulAssert(!_var.empty());
93
    ++m_currentVersions[_var];
94
}
95

96
private:
97
struct VersionedVariable
98
{
99
    YulName name;
100
    std::size_t version = 0;
101

102
    auto operator<=>(VersionedVariable const&) const = default;
103
};

Finally, withCurrentVersion and explore read that version and use it to look up the cached offset:

88
KnowledgeBase::VersionedVariable KnowledgeBase::withCurrentVersion(YulName _var) const
89
{
90
    return {
91
        .name = _var,
92
        .version = util::valueOrDefault(m_currentVersions, _var, 0U)
93
    };
94
}
95

96
KnowledgeBase::VariableOffset KnowledgeBase::explore(YulName _var)
97
{
98
    yulAssert(!_var.empty());
99
    VersionedVariable const currentVar = withCurrentVersion(_var);
100
    AssignedValue const* assignedValueWrapper = m_variableValues(_var);
101
    Expression const* assignedValue = assignedValueWrapper ? assignedValueWrapper->value : nullptr;
102
    // A versioned variable always refers to the same value,
103
    // so we check if we already computed it
104
    if (CachedOffset const* cachedOffset = util::valueOrNullptr(m_offsets, currentVar))

The old and new values of v now have different cache keys. A store whose address might alias a invalidates the remembered value, so the load stays correct.